Many people are looking to transition or start their careers in data analytics, engineering or programming and, sometimes, they feel lost. I know that feeling. I started a career in finance when really I wanted to do programming. So, after a few years in finance, I looked to transition to software, and nobody would take me seriously, even though I had practised a lot.
My first experience with data was building a database in FileMaker many years ago. It was my first job, and gosh, did I make mistakes! I was 22, and back then, I knew nothing about SQL and didn’t understand databases either. Moreover, I didn’t graduate in computer science or a STEM field. Instead, I graduated in economics, so my technology background was not well-developed.
I faced technology and data again a few years later when writing my master thesis in Denmark at Aarhus University. There, I used a UI based statistical tool called “SPSS”. SPSS was great, but it required heavy data preparation… enter SQL, R and Python. I loaded data into SQLite databases, ran SQL queries to compute smaller subsets, and then used R to do regression analysis. Soon enough, R replaced SPSS entirely.
I wanted to work with data, and I was highly motivated. Yet I still lacked a solid mathematical foundation, so I ended up in finance, which somewhat reminded me of data. Back then, the cloud didn’t exist, Python was unknown, and VBA was still in use… so I got a job and ended up spending five years digging into Excel sheets. Finance was precious business knowledge, but it was hard for me to keep motivated with spreadsheets. So I spent a lot of my free time learning Python, SQL and Web Development.
After finance, I made a horizontal move and became an Analytics Manager. Finally! As Analytics Manager, I migrated my team away from UI ETL tools to Python, SQL and, a little later, AWS.
I have learned most programming skills by myself, taking incisive courses here and there and reading lots of books and articles. Then, using the knowledge I gained, I trained 20+ people, many of whom became data analysts and data engineers. The majority then became invaluable team members within dyvenia, the data company I started not long ago.
Do you know what I discovered? When people get how they can learn efficiently and then put in the effort, they always grow.
I am convinced that anyone can learn programming and data. I also know that learners need to:
focus on what they are doing,
Want to be a data professional? Learn how to learn
I have interviewed many potential candidates looking to jump into data engineering or analytics. I can attest that employees are taking notice of IT these days. Still, unfortunately, their approach to acquiring these new technology skills is less than ideal.
At one of our workshops, I had the opportunity to talk to a few people looking to transition into IT from roles such as mechanical engineering and accounting. I spoke to a very bright and motivated person in one of the conversations. He told me about all the great things he was learning on Udemy and Youtube. Courses. Many, many courses!
Writing software, however, requires a significant amount of practice. So, you want to learn Python programming? The best you can do is program something using Python.
There is a time for courses, and there is a time for building. I like to think of 2 types of learning for data professionals: focused learning and academic learning.
What is focused learning?
Back in high school, English classes were my most dreaded. I tried my best to avoid them, usually spending most of my time wandering the school corridors. Finally, I convinced myself I was terrible at languages. I was doomed to speak Italian for the rest of my life (poorly). Then I took private Spanish classes, and things drastically changed.
Thinking back on those experiences, I see why I became excited about Spanish and could not stand English. Spanish had three significant advantages:
The teacher had us using the language from day 1;
She would never speak Italian to us, we had to know Spanish;
The teacher was OK if we made mistakes; she just wanted us to practice.
I loved Spanish literature; I needed Spanish to appreciate it even more.
Learning a subject to fulfill a need we deeply care about is highly effective because it focuses our minds on what is essential. Focused learning is, in my opinion, the fastest way to learn a craft; programming and data analytics are both crafts at their core.
Focused learning is learning to accomplish something
Why is focused learning an effective way to learn a craft? Interestingly enough, it’s effective because it puts learning in second place. Your goal is not learning per se but achieving something you want to accomplish. Here, the “focus” word stands for “focus on learning only the bits you need to do your thing”.
What is academic learning?
Despite dreading English, there were subjects in high school I loved. One of them was math. Math was great because it pushed my mental limits as I built an understanding of abstract concepts. The math I studied in high school was so deep that I still remember it today. It was various levels more advanced than the Economics math I took in University.
Math itself never earned me a job or a serious accomplishment. On the other hand, my math knowledge has been vital, but always in an indirect way. For instance, when working in finance, I could quickly develop math formulas to calculate various ratios used to run massive businesses.
And I feel this is the thing with academic learning. It provides excellent “background knowledge”, but it does not stand on its own, especially when building something. It might be a different story for things such as theoretical physics.
Academic learning is understanding the deep theories behind how something works
Suppose we go back to learning languages. Focused learning is like learning a language by speaking with people but having nothing else than “intuition” and “understanding” of the core concepts. Academic learning is like learning a language from books, studying grammar rules, and reading literature. They are both useful, but if you move to a new country and need to learn fast, you better reach out for focused learning. If you are like me and like digging deep, you can do the academic learning later to strengthen your craft.
The data professional craft with focused learning
I am not going to write about academic learning. It has its place, but I assume that you, the readers of this article, want to become a data professional fast. In my experience, the academic way of learning is not fast, and it could make you look confused at interviews because of how broad it can be. For that reason, I deal with focused learning only from now on.
For focused learning, the first step is to find something worth accomplishing. Remember: there is no focused learning without something to achieve and build. In our data world, accomplishment usually means programming applications or data models. To be clear, this means writing code, configuration files and SQL queries.
On building things during focused learning
So at the beginning of your journey, you need ideas. Ask yourself – what can you build?
There are many things you could build. However, I suggest you start very simple. I will put some build recipes here later on, but I recommend building something small for now.
When mentoring aspiring data practitioners, my team at dyvenia and I have noticed a few recurring patterns in beginners:
A tendency to tackle too many significant learnings at the same time (focused learning but without focus)
A tendency to consume a lot of theoretical content and enter a sort of analysis paralysis
Listening skills, many beginners have to be told to take notes when receiving instructions or feedback
A lack of focus on good communication, which in turn makes it hard to give expert feedback because it’s hard to understand the problem the learner is facing
Over time, we came up with a few solutions to the problems above. While discussing these solutions, we started seeing an overall solution, which we now call “the BUS framework” for focused learning.
BUS: Break it down, Understand, Share
Following the BUS framework may help tackle your development quickly and pragmatically by structuring it in three stages.
The BUS acronym represents the three stages. Quickly, before I explain further, think of your development idea. Got it? Good, now let’s look at the stages.
Break your idea down. Out of the entire thing you want to accomplish, scope down a small use case you can learn and test in a few days. It doesn’t matter what it is, but it should allow you to build and test a small demo.
Understand by doing. Learn by building something, and don’t be afraid to make mistakes! While working, ask yourself why you are doing things the way you do them? This question will help you deepen your understanding, but don’t try to understand too profoundly to avoid “analysis paralysis”.
Share your thoughts. Share your results with the world, seek feedback and teach others, keep iterating
Image above: To help our team members memorize the framework, we developed a simple illustration of a bus with some of our team members on it.
In brief: to develop rapidly, you need to do things, learn how what you do works and share what you learnt with others.
In dyvenia, we add the sharing element to everyone’s development. We do that because sharing, which is communicating and teaching, solidifies knowledge and builds rapport in our teams.
Let’s now take a closer look at each phase.
How to break it down
I advise creating a small project using the technology stack you want to be hired for. For example, are you looking to become a data analyst? Build some Python notebooks and put them on Github. Are you looking to become a data engineer? Create some docker-compose files and test them out on a real server (using one of the many cheap virtual server providers). Are you looking to become a cloud engineer? Same with potatoes, write some Terraform, Cloudformation or ARM files and make sure they work on a known Cloud platform.
However, the number one thing to keep in mind when building software projects is to start small. Break down your ideas into smaller and smaller chunks and try to get to a piece you can deliver in a few days. If you are new to Python, the first chunk of your project should be printing “hello world”, but you should know how the complete, end-to-end project on Github will look.
Here is a simple breakdown example:
Development Idea: I want to learn Python so that I can become a Data Scientist
Big goal, right? It’s a great goal, but it’s too broad. See how I make it into something specific you can start working on right now:
Big Dream: I want to learn Python for data science
Still too big: I want to do machine learning with Python
Less big but still too big: I want to be able to sum some values
Realising expectation: I want to get some data to play with into a Python variable
More specific: OK, I have this data in Excel I want to analyse
The task: OK, how to read the data from Excel into Python <- stop here, do this
As you can see, we are looking to get specific with stage B. But, unfortunately, your development idea is at the same time your North Star and your worst enemy. Too much focus on your big development idea, and you enter analysis paralysis (trust me, I’ve been there many times).
Are you able to tell me, step by step, what you plan on doing? Can you hear “ANDs”?
How does success look? How does the outcome look?
How long do you estimate to accomplish this task?
How to understand
I like to say “understand by doing” because it implies doing something for the sake of developing a solid understanding of your craft, step by step.
Understanding something new in the context of focused learning requires three things:
Understanding enough theoretical background, how the thing works, emphasising “enough” here.
Testing your understanding with real case scenarios by writing code, configuration files or SQL queries if we narrow it down to data professionals, and then
Being able to explain why you did something the way you did it.
The biggest challenge we have at dyvenia is beginners focusing only on theoretical background. Sure, consuming courses, books and articles can help. But, to become a musician, you need to play instruments, so to become a programmer, you need to code.
Here are some good questions to ask yourself during this phase:
How can I tweak this to make it do something different?
Why do I get this error message? What is it trying to tell me? (Yes, read error messages)
What are the entities I am working with? How are they reflected in my data structure?
Can I refactor this code? Does it smell? (don’t over-focus on this, but understand it and do it at some point)
An excellent way to understand stuff, in general, is to see how the data changes. So at its core, all computing is about changing data somehow.
Let’s continue the example from the “break it down” section above, starting with the task:
The Task: OK, how to read data from Excel into Python <- stop here, do this
Understanding 1: there are many ways to do this; how do they differ?
Understanding 2: what is the terminology? Can I learn some industry-specific words? What do these words mean?
Understanding 3: is this similar to anything else I know already? How does it compare, and why?
Why are you doing it this way?
Watch for terminology; how are the things you are using named and why?
What did you learn from this?
How to share
When discussing the BUS framework with my team, a colleague told me about an aspiring writer from her high school. To hone his craft, the writer relentlessly shared his writings with a local forum and asked other users to share their feedback. He had been doing this for years. So where is this guy today? He published his first (award-winning) novel while still in high school; his movies have been screened at Cannes and selected for an Oscar.
Along with so many other similar stories, his example shows us how super easy sharing is today: Just write something and publish it on the web, done. Yes, sharing doesn’t have to be face-to-face or based on meeting people. It can be as easy as writing a forum, blog post, or article to explain a concept or technical documentation.
When you write, imagine that you are teaching. Doing this will help you develop your thoughts and deepen your understanding. Focus your sharing on simple, to the point statements. When preparing your content, continuously keep in mind the following questions:
How is what I am writing helping my audience?
Will someone with less knowledge understand what I am saying here?
Is my vocabulary precise and based on established definitions (if not, share your definitions with your audience)? Are my sentences simple enough? If not, break them down.
Avoid using too many adverbs or embellishments in your writing. Be aware of the type of document you are creating. For technical writing, I suggest following the diataxis framework.
When you find people to share with, show up prepared. Structure your thoughts before a meeting and even prepare a list of your talking/discussion points. Verbal communication is not as structured as writing. It helps to have a few notes at hand, to stay on track and guide the conversation (believe me, this will earn you bonus points with your mentor).
Ultimately, the way you will share is entirely up to your learning style. Just make sure that you are succinct, structured and easy to understand.
Which audience are you addressing with your communication? Are you answering their questions?
How specific is your communication? Is it addressing particular problems?
How to engage in expert feedback
You can develop robust technology skills independently, and I strongly recommend getting started because getting feedback from experts will take time. Experts are generally very busy because technology knowledge is scarce, so they may not be very patient with beginner questions.
I recommend looking for online communities, meetups or even friends in your existing network if you struggle to find expert teachers. It is possible to get expert reviews this way, provided you do the necessary leg work first.
In dyvenia, we offer apprenticeship levels so candidates at the beginning of their technology development or learning something new can still join and get expert teaching.
However, despite being paid to learn, if you want to become a good data practitioner with sought after skills, you will need to invest your private time. Probably lots of it. Although the “10,000 hours to become a master” myth has been debunked, the experience shows that becoming good at something requires a firm commitment beyond regular work-day hours.
When you meet an expert: do the pre-work
For the love of God, if you do find an expert, don’t go to them asking confused questions about stuff you barely understand. You will not get good results this way, and you may also annoy the expert!
First and foremost, apply the framework you just learned about in this article: Break it Down, Understand, Share. Very important: do not skip on the first step. Most beginners don’t break down their learning and try to cope with the entire thing right away. This is akin to what Derek Sivers calls version infinity. When you try to cope with too much stuff, you won’t understand well what you are doing and, most importantly, you will make it very hard for your experts and mentors to help you.
Spend time beforehand to formulate your questions. If you notice experts don’t understand your questions right away, you did not break them down enough. When you break questions down, they can get very specific. Experts love specific because it is a lot easier to understand.
Here are two questions. See which one is easier to give feedback on:
My SQL statement does not work. Can you help me?
I tried to follow this guide on CREATE TABLE to create a table in my SQLite database. However, I get an “INT Error” on column “Address”. Could you help me understand why? Here is the query I wrote.
Question 2, right? The learner broke down their work on question 2 because they focused on specific aspects. They also provided a link to the tutorial they are following and the SQL query text. A SQL expert can answer a question like this in 5 minutes.
What about question 1? Our learner is not breaking down their task here, and because of that, their question is too generic. Generic questions are hard to answer for experts because they need to pursue all the background information.
It gets hard for an expert to give you feedback if you repeat the same mistakes. So here is one little trick: take notes, and then after you take them, go through them with the expert, together, to see if your understanding is correct.
Listening is an art, and it comes with experience. Experts are humans, and they don’t always give you clear feedback or advice. This is why it is so important to listen attentively and check back with them if your understanding is correct. So don’t be afraid to ask follow-up questions.
If your expert is doing all the talking, you aren’t listening. So you need to constantly check your understanding, take notes, and contribute to the conversation even if you don’t know the topic well. This way, the learning will stick in your mind, and you will continue your development progress.
Make sure that you recap key takeaways of the conversation at the end of the discussion. This way, you will ensure that your understanding is correct, and it will also help you catch any essential ideas you missed.
Take a deep breath and count to three
Getting expert feedback can be frightening, but guess what experts adore? Talking about their craft! They want to help you, and if you ask questions, they will likely enjoy the interaction.
If you are struggling to break things down, show the BUS framework to the expert and ask them to help you go through the stages. Tell them about your big idea, that you know this idea is too big, and see if they can coach you into breaking it down. I can assure you that any expert out there knows how to break big ideas down into actionable steps.
Two final thoughts come to me, and both are sayings from wise people. The first saying tells us that “Success is the sum of small efforts, repeated day-in, and day-out”, and the second one reminds us that the key to success is preparation.
HOPEFULLY, the BUS framework will help you operationalise this advice and be your blueprint for successful development.
Perhaps you will struggle a little initially because this approach probably challenges the way you have been working so far. However, I encourage you to make mistakes; they are a valuable source of experience and insight. And then BUS them as well:
Break them down and inspect the steps you took;
Understand what went wrong and what your findings are teaching you.
Share them with your friends, community and mentors. Let them know your learnings and discuss them with you. Allow them to show you different perspectives on your work.
And best of luck. Remember, you got this!