Life Patterns

….

Learning

Do you know how to learn?

Learning to learn is one of the most important skills that you can have, and in fact, that is the main skill to learn from school and life. This is ironic, since usually very little time is spent at school and life in learning out to learn.

Learning is like a muscle, the more you do it, the better your become. And just like in sports, there are specific techniques that you can use to learn more efficiently.

As a developer if you are not passionate about learning, you are on the wrong job!

It is not about learning one, or two or three programming languages or development frameworks. You need to learn 10+ languages and be on a constant learning curve. Each language will tech you something new (don’t worry, only the first 5 will be hard, after that, the key paradigms will always feel familiar). For example, it is very hard to learn about functional programming until you start coding in Node or in Scala (after banging your head against the wall for a bit, it will click, and you will love its power and ability to write really simple code)

It is about learning new paradigms, about interconnecting your skills. What you learn in one domain, will be applicable in another. For example, being a better musician, artist, athlete, car mechanic or philosopher will make you a better developer

Application Security (AppSec) will take this to another level, since you will be asked to code review in all sorts of languages (which is great, since that is the best way to learn). AppSec focus on how ‘it’ really works, now just how it behaves.

The reality is that we are in age of the ‘professional amateur’, where you very rarely have time to really specialize in a particular language or technology. And when you do specialize, if you are not careful, you will be stuck in the past and be the one that is responsible for maintaining the legacy applications.

The best description I’ve read about how learning occurs is in the Badass: Making Users Awesome book, where Kathy Sierra outlines two key requirements to learn:

  • Practice right - it is not about how much one practices, but how effective that practice is. This is connected with the idea of being in ‘the zone’ and it really shows that the real talent is not in being good/excellent in a particular area (for example playing guitar) but it is having the ability and perseverance to practice and learn effectively. Ironically too much talent can actually back fire, since it makes the first part easy and doesn’t prepare the student for the hard road ahead. One of my best teachers always said “being good is 1% talent and 99% perspiration’
  • Consume large amounts of good examples - the very interesting data point here is how much we learn subliminally and by osmosis. Related to the idea that books are much better mediums to learn, when we learn we absorb much more that we think we do. This is why it is so important to keep seeing (and learning from) good examples of what we are are trying to learn. When we see or read from somebody that has gained mastery of a particular topic, we are learning all sorts of things. This is why as a developer is is key that you read lots of source code and try lots of technologies, since each one will teach you much more than you realise. Remember that all Open Source code is available (usually on GitHub). Spent time on projects you use and dig deep into the source code.

What you really should to be worried about is when you stop learning.

Ironically this can happen the more you move up the company’s corporate ladder. There is a big trap of management, which pushes highly technical and proficient developers into ‘management’ or ‘architectural’ positions (this is also called the Peters Principle where “employees are promoted to the maximum of their incompetence”). When this happens, these highly knowledgeable professionals have very little time to spend on technical issues, spending most of of their on meetings, spreadsheets and ‘non learning activities’

Here are some ideas for how to keep the technical skills up-to-date:

  • Be involved as a technical resources (not as a manager) for a couple hours per week in real-world projects (ideally around cloud solutions or incident handling)
  • ask the team to create DSLs (Domain Specific Languages) that abstract their work into easy to code components, and then write code on top of those DSLs
  • write and review tests (best way to learn is to read source code, specially unit/integration tests, since they tell the story of what is being tested)
  • write integration scripts to automate day-to-day tasks (for example using Zapier and AWS Lambdas)

My view is that no matter your role, you must make sure that you remain highly technical, have a deep understanding of what is going on, and always keep learning. Programming is one of the best ways to do this.

Work in a learning environment

Ideally this learning environment will be part of your job.

If not, then evenings and weekends are a great time to learn, while you find another job that puts learning at the center of their ecosystem

If you are learning things you are passionate about, the extra effort to learn should feel easy, and actually be relaxing.

Be a founder

The single thing that you personally control when you go to work, is your attitude to your work and how you approach it.

One of the concepts that I really like is the idea that you should “act like one of the founders of the business”.

Image you where employee #4 and you really cared deeply about the company you currently are working on!

Ask yourself:

“If I was a founder of the company/department/section I work now, with the responsibilities that I have at the moment: “

  • “How would I behave everyday?”
  • “What needs to be done now, that will make a big difference?”
  • “What can I do that will help?”
  • “What would I do differently?”
  • “What values and principles would I fight for?”

Hopefully you will get some interesting ideas and actions (from this mental exercise)

The question now is: “what is stopping you from doing just that?”

Who is telling you “Don’t do it”?

At the moment it is just you!

You can even do this for companies that don’t employ you. You can contribute to their open source projects, you can write blog posts about them (and use twitter to reach out to key individuals)

You can choose to care about the team that you are currently in, and the work that needs to be done.

The irony is that the more you care and the more you behave like a founder, the more value you usually add and the more valuable you will become for that company.

Being criticized is an privilege

One of the most important life lessons you need to learn, is to how to give and receive feedback. Specially when the feedback is not positive, and it is criticizing something you’ve said or done.

My view is that a very effective way to learn (and adjust behavior) is to create environments where your friends and colleges are conformable in criticizing your actions (i.e. to provide their views on how you behave and act). This is not easy, and is something that I work hard at it, specially since my high-level of energy can very easily create blind spots in my understanding of the real impact of my actions (see Why do others think that I’m “hard to deal with” and that “I don’t listen”).

If you are lucky enough to be in a position where you are criticized, you should see that as a privilege and an asset that you have.

But listening to somebody (and their criticisms) doesn’t mean that you have to agree with what they say and do what they tell you to do :)

What it means is that you understand their point of view. Also important is that you let them know that you’ve acknowledged their feedback and will consider their ideas.

Here are three models I use for the cases when I don’t agree with somebody:

Usually, disagreeing and committing is a much better outcome, since that makes sure that all parties are aligned in the right objective or idea.

Agreeing to Disagree is a close 2nd since that means that you were able to reach a consensus that both don’t have the same view on a particular idea/subject/behaviors.

Sometimes, specially in the social media world (or Open Source world) there are tons of people with lots of ‘half-baked ideas and criticisms’, where the only rational and effective solution is to ignore them (or block them)

Note: always ignore and block trolls and other online personas who are completely irrational, and only bring negativity to the table. They are not worth it, and you will learn nothing from them.

Learn who is your public persona

Part of the exercise is to tune in your understanding of reality, with what is really going on.

You need to build trust relationships with your community, where your friends and colleagues (both up and down the org chart) are comfortable in telling you what they really think about you and how you behave.

I really like the concept that “if you want to go fast you can go alone”, but “if you want to go far (and have sustainability), you need to work with a team”.

Nobody creates anything that is valuable by itself. It is always a team effort, and you need to learn how to be an effective team player (regardless of what position you are playing at that moment in time)

One of the key concepts that I have in my mind is the fact you can’t control how somebody will react to your actions. So don’t fight it and use those reactions in your feedback loop, and become a better person, professional and manager.

Myers–Briggs and 16 personalities

Does this means that you need to react differently to different people?

Yes! Absolutely.

A feedback from person A could set a number of alert bells in your head (as in ‘… Hummm… I might be going on the wrong direction …‘), but the exact same feedback from person B could give you a confirmation that you are indeed going on the right direction :)

The way to do this is to reverse-engineer how somebody behaves and think, and apply that filter to what they say. The fact is that people are different and they will react differently to the same situation.

Myers–Briggs Type Indicator is a really good framework to understand this where most people can be split into 8 learning styles:

  • Extraversion vs Introversion
  • Sensing vs Intuition
  • Thinking vs Feeling
  • Judging vs Perceiving

Another related framework is the _Big Five Personality Traits which maps five factors:

  • Openness to experience (inventive/curious vs. consistent/cautious)
  • Conscientiousness (efficient/organized vs. easy-going/careless)
  • Extraversion (outgoing/energetic vs. solitary/reserved)
  • Agreeableness (friendly/compassionate vs. challenging/detached)
  • Neuroticism (sensitive/nervous vs. secure/confident)

To see both of these frameworks in action see the 16personalities.com website who have merged these two frameworks and come up with with 16 different personalities:

For reference here is mine :)

Note that although these frameworks might not be 100% accurate, I found the results I’ve seen to be quite exact in practice.

Learn about how the mind works

One topic that has really help me to grow and understand better how to work in teams is the amazing Neuroscience and Behavioural research that has been published recently in books like:

Importance of diversity and balance in teams

One of the key reasons why a diverse team is so important, is because having teams made of individuals of primarily one type, will invariably create blind spots, promote GroupThink and lead to bad decisions. This is a point that Jane raises in her InSecurity: Why a Failure to Attract and Retain Women in Cybersecurity is Making Us All Less Safe book (i.e. having cyber risk decisions being made by a predominately male population does not usually result in the best possible outcome)

Being aware of the team members personalities is a great way to ensure that the right mix or the right balance exists.

Radical Candour

As a framework to think about feedback I really like the ideas presented in the Radical Candor book, which provide a mental model based on two main axis of behavior: Care Personally and Challenge directly:

  • When you Care Personally, but Don’t Challenge directly: you have Ruinous Empathy (meaning that real feedback is not provided until it is usually too late)
  • When you Don’t Care Personally and Don’t Challenge directly: you have Manipulative Insincerity (which is really something you don’t want to be involved in)
  • When you Don’t Care Personally but Challenge directly: you have Obnoxious Aggression (which is not a good way to communicate and is bound to make the recipient very reactive and even aggressive)
  • When you Care Personally and Challenge directly: you have Radical Candor (which is the sweet spot, when the message has the maximum opportunity of being listened to)

Note that this is not easy at all to put in practice, Radical Candor does required a lot of work and effort from both parties. For example, we usually start by saying ‘Ok I want to give you some Radical Candor…‘ which is usually a good way to kickstart the conversation and prime all parties for what is going to happen next.

It is not easy to give feedback

Although for some personality types it seems that all they can do is to give feedback (which can also be a defence mechanism to cover up for insecurity), the best feedback you can receive is one that is hard to give. You need to be very humble when receiving feedback and appreciate that it is very hard for the other person to do it (since they are going ‘on the record’, and in most cases it is easier to not say anything)

Remember that if somebody has something to say to you, but is afraid to say it, or thinks that it wont matter because you will not listen, the real loser in this lack of communication is you (not them).

The worse situation you can be in, is being ignored and not knowing what is really going on. You want to make sure that your colleagues are conformable saying to your face, what they say (or think) behind your back.

Learn to like criticism and use it to measure success

The way I try to cope with criticism and comments, is to view them as positive things and even try to enjoy them (which is not easy at all to do, and it does require a lot of practice and soul searching)

A good mental model is to accept that you will always be criticized, and there will always somebody/somewhere that doesn’t like what you have just done, or doesn’t understand your point of view. With this in mind, what you need to do is to use the ‘what’ is being criticized as the benchmark of your progress.

Basically you should measure your evolution by what you are being criticized for. Learn to recognize what are side effects of your current path, and use that feedback to confirm your current trajectory.

Always focus on the ideas

Here is an amazing quote from Eleanor Roosevelt: “Great minds discuss ideas; average minds discuss events; small minds discuss people”.

Always focus on the Idea, and don’t worry about how that was said (the Event) and who said it (The People)

Music and criticism

One of my first big lessons in the power of listening to the right people for what they say, was when I was playing drums professionally and I realized that the best feedback (and criticism) that we received, was not from other musicians (who could be very objective in what was wrong), but it was from audience members (and long standing fans) who really cared about the band and the music.

I was quite curious on why this happened. Why didn’t the most qualified individuals to provide feedback (the musicians or music critics), were the ones that really deserved to be listened to? (in fact some of their comments would fall on the ‘ignore’ bucket).

Here are some thoughts:

  • most musicians are not very good teachers and don’t know how to give effective feedback (they usually to much focus on technical aspect of the playing)
  • they are not the target audience
  • (some) could have conflict of interests (and not really be interested in your success or improvement)

Note that this doesn’t mean that there wasn’t value in those musicians comments, it was just that they needed to be heavily filtered.

On the other hand, the criticisms from the audience, would be much more raw and consumable (if you talk to them and get them to give you real feedback).

Related to this is the fact that what I don’t really like is praise and compliments, since after the nth variation of ‘you looked/sounded great’, you don’t really learn a lot (and most people will default to vanilla compliments).

Finally the positive feedback that is really, really, really valuable is the feedback from the people that you respect the most (which are usually the ones that give you radical candor).

THAT is usually all that you should be looking for.

THAT moment when one of your heroes (or individuals you really respect) gives you a gentle nod of ‘well done , that was good!’.

In your life, you will be on the receiving end of many magic moments like this. Unfortunately most miss it and fail to appreciate them. Make sure you celebrate them as they occur, since nothing else matters (money, success, fame).

In life, always celebrate and enjoy the journey (and don’t forget to do the happy dance on your milestones and successes).

Because the moment you reach your destination, is the moment you start to look for the next challenge (with a new set of expectations)

Backup your life

Backing up your code (and ideas) is one of the most important patterns that you must master. Your current approach to backups will depend on how much have you lost, and how painful it was.

The reality is that sometime and somewhere in the future, you will lose some of your data (and ideas).

This could be something as simple as a lost laptop, or some data that was deleted by accident, or even an ransomware attack that encrypted all the files in your devices or servers. If you don’t have a good strategy and habits for how you do your backups, it is just a matter of time before you have a catastrophic event.

Trust me, there are few things in life more soul destroying and demotivating, than having to re-create something again (that you were happy with and you had spent a lot of time creating). Even worse when you are not able to recreate it, which in a business environment can easily lead to you being fired for lack of due-diligence or negligence.

The solution is to think about where you classify and store your data (and ideas), so that you can come up with strategies that work in your day-to-day activities.

I’m going to provide a number of examples of how I do it, which hopefully will give you some ideas:

  • Secrets Minimisation - From a security point of view, the less secrets you have the better (and the easier it is to backup the rest). This is where the more you embrace the idea to publish as much of your data (and ideas) as possible, the easier it is to use web based services as your backup medium.
  • Passwords - A clearly important piece of data not to lose or disclose. My strategy is to pick formulas that I can remember and to use 2FA authentication (like SMS) as much as possible (which dramatically reduce the importance of passwords)
  • Future Self - Part of my drive to share, is to think that one day in the future, my future self will need it. This is also why I like to Open Source as much as as possible, since it makes sure that as I move jobs, I don’t have to start from scratch (for example what happened with me and the O2 Platform research or the Maturity Model tool I developed recently)
  • Git - Git is not just a version control which you use when you want to commit to the main repo. I’ve seen developers that code for days before doing a commit. This is missing a massive trick. Not only during those periods between commits there is a high risk of data loss, the developer is also missing the opportunity to go back to a version created a couple hours ago (which was better than the current one). Basically there is only so much Ctrl-Z can help you. Note that you should be using git to store as much data (and ideas) as possible, since this workflow is not just for source code (another reason why I like to use markdown for content and DOT for graphs)
  • Autosave and Commits - When using git as a data store, I always enable auto-save on the IDEs so that I never have unsaved text in memory. I then use git commits (and git staging) to really understand what has been changed (and to double check those changes before committing to the target branch). This is very empowering and liberating, since I don’t really worry about losing anything
  • GitHub - I push as much code (and ideas) on GitHub as possible. For example I have repos (some private) that act like document storage and (literally) backups. My expectation is that GitHub’s backup strategy is sound and better than mine.
  • DropBox and GDocs - Same thing for DropBox and Google Docs. I use them to store data and rely (as most companies do) on their security and backups (very important to have 2FA on these accounts and to pay for the commercial versions, which provide features like version control and much more storage)
  • Twitter - I use twitter as my personal search engine, and use it to store all sort of links and ideas that I might be interested in the future
  • Google - A great site effect of putting your data (and ideas) online on a public and hyperlinked location (for example on a blog or slideshare), is that Google (and Web Archive project) will eventually index it (and keep a copy for ever). I actually have used these service’s caches to recover ideas that I published ages ago, on a platform or site that has since disappeared!
  • Simulate disaster - Ask yourself, if you lost your laptop now, how painful it would be? For example at this very moment, the only thing I would lose if my laptop disappeared (or was stolen) would be the text in this chapter (and in about 30m, I wouldn’t lose anything, since I will have committed this text into Git and GitHub)
  • External Drives - For large files and VM (not really much these days) I also have a number of external drives in my house that hold it (although some of the most interesting research VMs, like the ones I was using when developing the O2 Platform, have been moved to dropbox)

Finally, you probably noticed that every time I mentioned code I also added a note about ‘ideas’. The reason is that you also need to backup your ideas so that your future self has access to them. The reality is that you will forget about those ideas and the connections that got you there. The only way to make sure they are not lost forever is to publish them into an hyperlinked medium.

You basically need to backup your life!

Please make sure that when (not if) some of your devices lose (or encrypt) your creations, you have a quick and efficient way to recover them.

Talking to yourself digitally

Talking to yourself in an digital way is not a sign of madness :)

It is a sign that you are capturing your ideas, knowledge and workflow.

I do this a lot, since I find that it gives me a way to capture what I’m doing in a format that I can easily access later. I’m hyperlinking my knowledge/ideas and speaking to my future self.

By talking to yourself, I basically mean that you are having digital threads (on git commits, github threads, blogs, twitter or slack) where the main person talking (i.e. adding digital content) is you. You describe a problem you have, you write possible solutions and when you find the answer you document that too.

It is very important to be comfortable in talking to yourself digitally, since it is not easy and it can feel quite awkward. But it is totally worth it, usually the main beneficially of those threads is actually you (I have many examples of years later finding blog posts I wrote where the step-by-step details I posted help me not to have to solve the same problem again). That said one of the loneliest moments you can have is when you have a particular problem and the only thread you find on the Internet is actually you a couple years ago talking about that problem and asking for help (it is in that moment that you realise that you are the only one in the world that cares about that issue :) )

Usually the reason why you will not do this is because you think (wrongly) that:

  • Nobody will be interested in this info - this is wrong. Posting your ideas and workflows will help others to understand your thinking and actions. It leaves your workflow behind, which is where the really learning occurs. The worse part is that if you do document the solution later, when describing a journey from ‘A to F’, you will describe the final solution as linear A, B,C,D,E and F steps. In fact, in practice when solving the problem the first time, you actually went on an number of tangents which are as interesting and valuable as the final solution. In this ‘A to F’ example the path you took was actually A,B, G, M,Z, T, E, D and finally the F steps (usually the final solution was not discovered in an linear and in-sequence way)
  • This info is obvious - caused by the ‘curse of knowledge’ where now that you understand it, the solution is obvious (except that it wasn’t obvious to you before you solved it)
  • I will look stupid by asking this question (and providing the answer) - There are no stupid questions! If you did not knew the answer then that was a valid question (usually the gap is in the way knowledge is shared and captured in your environment). Everybody was a novice once, and did not know that answer! That said, what can be very annoying and counter-productive are the individuals that keep asking the same question and not learning (so as long as you keep learning, you should share your questions, and when you find them, your answers). In fact a really good side effect (in teams) for sharing simpler questions, is that it lowers the bar of what is a question that can be asked, and it can dramatically increases collaboration and team knowledge propagation.
  • Who am I to say this - caused by ‘impostor syndrome’ where you are your worse enemy

The future needs you

Sometimes the future just doesn’t happen! It needs people like you to make the difference.

Re-enforcing the concept that what matters is not ideas but energy and focus in execution, there are a number of ideas that although brilliant, we still need the right individuals at the right place in order for them to become a reality.

This happens in all fields (for example there is a great interview by Elon Musk where he talks about how the concorde and moon landings are good examples of us going backwards in technological capabilities).

On the developing/coding world, in addition to the WallbyJS (real-time unit test execution and code-coverage visualisation) that I cannot understand why all IDEs do not replicate and deeply integrate those capabilities in their engines, another amazing example is the Zoetrope (Interacting with the Ephemeral Web) research by Adobe.

This research was published in this YouTube video, and it shows a working real-time time machine for web pages (and other content).

This research transformed the Ephemeral and ‘no-past’ nature of web pages, into a multi-dimensional graph, where the previous versions of a page’s content can be visualised, transformed and analysed in all sorts of ways (check out the video and you will be blown away).

Given how powerful this idea is, the interesting question is “Why hasn’t it evolved!”.

My view is that because there is a significant amount of research and technology required to reach the workflow shown in that video, and the fact that the technology and ideas where not released under an Open Source license (or Creative Commons), any new attempts would have to start from scratch (since it clearly looks like Adobe did not continued the research projects)

Also important is that an individual’s vision and an sustainable economic model matter (i.e. someone who understand the problem and someone who is funding the research). Although the key concepts are clearly shown in the video and easy to understand, in the last 10 years we had not had an individual (or team) with the right energy and drive that has decided to replicate this research into an Open Source environment, and built a strong community around it.

I’m very frustrated by this lack of development, since there are tons of areas in Application Security where this kind of anti-ephemeral technology would be massively important.

Gen Z dev, if you are looking for a place to start replicating this idea, here is one for you:

Create a tool/website to search and visualise the git files history (for example how to do a search across previous versions of files)

That is not a problem that has been solved today, and not only you would let a lot about how git works, you would be creating a tool very useful to you and the development community. As an example that would allow for the easily discovery of secrets stored in git repos that have been ‘deleted’ using commits (which means that the secrets still exist in that repo and are available to anybody that can clone it)

Pick a vision and be the one that makes the difference

Part of your path as a Gen Z developer, is to find something that you are really passionate for which you can execute. The win-win scenario is when you pick an idea that either is quite new (like chaos engineering) or has been around for a while but the momentum has been lost. For example the Zoetrope mentioned here, or SAST technology (Static analysis of software/applications/infrastructure for finding security issues)