Shallow vs Deep Mindset

Every single activity we do in engineering is an opportunity. We need to see this way, with positivity, and do more than we are asked to. That's how we improve. PRO players from football, basketball, or any pro sports, practice like there is no tomorrow. Practice or training is one dimension, and another dimension is vision, we need to be able to see things differently. For instance, we live in an attention economy, the issue with such an economy is that is shallow, so we live in a shallow attention economy. We need to start seeing the opportunities and encouraging a deep mindset instead of a shallow mindset. A shallow mindset is okay as a starting point, but quickly we need to switch to a deep mindset. It's all about vision because we can execute the very same task with completely different takes: Shallow vs Deep Mindsets. 

Shallow Mindset

A shallow mindset could be seen as just doing the bare minimum. Here are some other ways to see the shallow mindset:

  • Just focusing on the speed of getting things done.
  • Getting it done quickly and dirty, with no deep analysis, architecture, or thought process
  • Make sure we get rid of the task, as soon as possible
  • Don't create decent testing 
  • Making sure we have 100% compliance, nothing more. 
  • Just Copy and Paste
  • Just Watch a video
  • Telling yourself "is probably okay". 
A shallow mindset is okay to get started, is okay to get "hooked" and establish some mindset, for instance, let's say you want to do coding POCs every day, them being shallow in the beginning is okay, because getting into a continuous mindset is more important. After a month, then you should be switching to a deep mindset. 

Watching a youtube video, or just copying the whole algorithm is fine, in the beginning, this is how we learn, we copy, and that's how bands start, they do covers, and later on, they create their own songs. Doing covers for 20 years, then we have a problem, why the band doesn't have their own songs, now covers for a couple of months are fine.

When going to a gym, there is no sense to keep lifting the same 5 pounds forever, we need to be gradually increasing the difficulty. That's how we improve and get better over time, that's the same with POCs, reading books, and delivering tech presentations, the "difficulty" needs to increase over time, otherwise, you are stuck doing hello worlds in all languages and master of none(By the way: Master of None is a good TV Show).

Again, you can start small, copy and paste as you will, but we need to progressively shift to harder things otherwise we will be stuck and just fooling ourselves. Getting better is something that is good for everybody, the company wins, the team wins, and the individual wins. 

To be absolutely clear, let me share, how we can apply the Shallow mindset, let's say we need to deliver a lightning talk on Java 21, let me show how we would do it (please don't do this at home - is a bad example):
  • Have slides full of text, we just copy from the internet
  • Copy full examples of code (don't even bother to understand the code)
  • DO NOT talk about PAIN POINT only talk about ABSTRACT promises of good things
  • DO NOT think about the tradeoffs.
  • DO NOT do any coding POC.
  • DO NOT perform any DRY RUN, and don't practice the presentation
  • Just do it at the last minute.
  • When presenting just read all the slides.
The results of this approach will not be good. We need to do it better. The issue here, is we are lacking vision, and instead of using the Lighting Talk as an opportunity to learn more and get better, we are just delivering compliance and poor results. 

A shallow mindset can be summarized as going to the beach but only getting water to the knees. 

Deep Mindset

A deep mindset is the very opposite. Here are other ways to see the Deep mindset:

  • Focusing on Speed and Quality.
  • Going Deep: Performing analysis, Designs, architecture, and observability work.
  • Make sure you think as comprehensive as possible.
  • Decent testing 
  • Going above and beyond compliance, always do way more than asked.
  • Do not copy and paste, create your own examples, and make sure they are good, simple, and make sense.
  • Watch videos, make notes, socialize, and debate with others.
  • Telling yourself "What I'm missing, I must be missing something, how this can get better?". 
The issue with the Deep mindset is obvious, is more difficult, will take more time, and will be challenging. Well, that's the whole point! It needs to be challenging, by following the deep mindset everything is an opportunity, even mundane simple tasks like:
  • Giving an Update on a JIRA ticket
  • Doing a coding POC
  • Adding Tests
  • Documenting something on a Wiki page
  • Delivering a Lighting talk presentation
  • Saying something in a meeting
  • Asking questions in a presentation
  • 10x other things that are not even listed here
A deep mindset is expansive and is what will make you get better. Sure, will be way more difficult in the beginning, and will make you suffer and struggle, but do you prefer the pain of growth or the pain of regret? 

Let's rethink our, Java 21, presentation, now following the Deep mindset:

  • Don't have slides full of text (follow presentation zen style).
  • Force yourself to learn, even if is painful and not fun.
  • Bother to understand the code samples in great length.
  • Talk about PAIN POINTs in a very practical way.
  • Think about the tradeoffs.
  • Do lots of coding POC.
  • Perform any DRY RUNs (3-5 times), practice the presentation with timers, and record yourself presenting.
  • Do it way ahead of time, months ahead, so you have time to go deep.
  • Do not just read the slides, say things are not in your slides, have notes, and be ready to present without slides.
The deep mindset will force you to learn things you don't know and you are not comfortable, again that's the whole point. A deep mindset will get easier over time, as you practice. 

A deep mindset can be summarized as going to the beach and doing a deep dive to see the bottom of the ocean. Hold on a second, I don't know how to swim and don't know how to dive, well that's the going to learn and go do it.


So deep dive is just for presentations? No. Is for everything. For all projects, all tasks, everything, and anything we do as professionals. That's how a high-performance team show be operating.

Continuous Improvements

A shallow mindset is a good way to start, but it cannot be done alone for a long time. A shallow mindset could be your starting point, but it cannot be the finishing point. Here is a summary comparing both mindsets:

Shallow vs Deep mindset

Combining a Shallow and Deep mindset is how we learn and if we keep repeating is how we will keep improving and keep raising the bar.

A shallow mindset, is an easy way to start something and should be the first step, but we can't stop there, evolving to a deep mindset is how we will learn effectively and really deliver great solutions, and great experiences for our consumers and how the whole level of the team and the org will get elevated.

Takeaways

So many takeaways here, but let's call out some of those:

  • Don't take anything for granted, do your best at all times.
  • There will always be pressure to release, and pressure to lean, pressure happens in any highly mature PRO sport, and this is not an excuse to not get better. 
  • Don't focus on excuses, focus on hard work. Focus on learning and doing. 
  • Your best cannot be static, it needs to evolve, and it always needs to be aiming for bigger difficulties.
  • Embrace the old and the new with a deep mindset, new frameworks, and old languages, does not matter, everything is an opportunity to do a deep dive and learn something new. 
  • Copy is okay to start but needs to evolve quickly to something deeper like debugging, reading the code, and doing deep dive coding POCs
  • Innovation is about doing things differently, not about doing the same over and over.
  • See everything as an opportunity to do differently to do better
  • Improving is a process, just keep doing it.
  • Believe! (Ted Lasso is a great TV highly recommended).

“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”

Cheers,

Diego Pacheco

Popular posts from this blog

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all languages in p
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail
read more »