I quickly found that the data engineering role meant, you’re going to be at the receiving end of the majority of the data that is used by the company, data really really familiar to them.
Learn the terminologies, understand what the abbreviations represent, identify the metrics and KPIs that will be thrown around you.
I learned a key lesson though, focus on the business use case rather than the fine details of the code. Every project folder, script or query addresses a specific use case and wading through the code base with that as a guide can help you quickly make sense of the code little by little. Then over time as you complete more tasks, you build a better intuition of the code.
So take it slow, you’re not expected to have the entire codebase in your head. Just focus on knowing enough so you know where to look.
This hurt me one time when I completed a ticket late because I felt it was my responsibility to figure out any confusion by myself.
After failing on this several times I learned the approach of typing a quick summary after each project meeting and sharing it with the stakeholder.
Aim to seek clarity before undertaking any assigned task. Engage the task issuer as soon as soon can be, jump on a quick call if you have to. It really shows you’re paying attention and you will deliver on tasks much much faster.
So brace yourself to be naive and painfully clueless at times. Don’t try to understand everything on your own, ask ask and ask!
Expect to make mistakes every once in a while but focus on owning them. I found that this was a much faster approach to making fewer mistakes overall
Owning your mistake means alerting your team as soon as possible and providing solutions to fix it, so it can be corrected.
I struggled with this initially, I just wanted to work in my small corner and produce the needed output, but I quickly found that my outputs as a data engineer depended on the inputs of several others and so it wasn’t that prudent.
Giving periodic updates to your stakeholders is one of the surest proofs that you’re working.
Communicate blockers too, you do not only yourself but your team and sometimes the larger business a disservice if you fail to communicate blockers in a timely manner.
For code blockers, I give myself up to 3 hours then I ask for help.
For issues with clarity of task requirements, I raise the flag immediately.
Well, I’m getting better at this, but yeah, communicate, communicate communicate.
Capture the feedback that will be communicated to you, take them in your stride and keep on moving.
Learn about yourself, be intentional about identifying what works for you; Maybe you’d find that your day gets messed up if you respond to emails early morning, Or that you thrive with minimal supervision than micromanaging, Or that you tend to do great work when there are no distractions around.
Over time you’re going to build a great intuition, which would help inform your next career step.
Finally, I really think it is a long road to mastery, and it takes time to build competency. So slow down, browse through some programming memes and laugh at yourself every once in a while.