DEV Community: Caleb Ariel

Navigating Your Career Path

Caleb Ariel — Tue, 14 Apr 2026 13:45:53 +0000

Whether you are looking to break into a new niche or scale the ladder in your current field, success requires a cycle of intentional exploration, strategic planning, and disciplined execution. Here are some insights from my experience and this amazing blog post

Explore

Starting with the end goal/goals is a great place to start. The thinking behind this, is reverse engineering the success that you want to see in your career or the goals that you have set for yourself, with as much specificity as possible.
Ask:

What would I like to accomplish?
What role do I want to end up in?
What do I want to be know for?

Plan

Once you answer these questions the road-map almost writes itself. Breaking down the process into the smallest next step.

This road map will also need some research into the skills and qualification you require. Reviewing job descriptions on platforms such as LinkedIn, Google or just ask your favorite LLM. Attending panel sessions, read articles and blog posts and listening podcasts that contain the insights from are in the role you see yourself is a no-brainer. Doing this will also help you learn about industry trends, pain-points and notice themes which give you a broader sense of the future of the role and demonstrate leadership skills in your current role.

Translate knowledge to action

Then comes the evaluation. Now that you know what's expected of you, what are the things that stood out and are missing from your arsenal? Identify a couple and work on closing them.

Iterate on execution and sharing your progress to get feedback and find ways to demonstrate your competence. After each gap you fill, it would be valuable to re-evaluate that list once more

Oh-no! I'm Stuck

This might only get you part of the way there and having session, as needed, with a mentor could prove extremely valuable in getting feedback on your journey so far, where you are stuck and what you need to improve on or resources to help you along.

Tips on receiving mentorship:

Whether you have a relationship with this person or not matters and changes your approach and the questions you'd ask.
Making it as easy for mentors to help you as possible by sharing you questions before hand shows that you value their time.
Giving your mentor an update, if you've followed their advice - even when things don't go as expected is a great way build that relationship.
If a one on one call might not be possible, perhaps suggesting async communication either via email or personal messaging goes a long way. Don't take it personally people are busy sometimes.
Sometimes the best "mentorship" is indirect. Reviewing and analyzing work from people you admire like reading papers, code-bases or blogs provides valuable insight into the.

Let me know if you found this helpful in the comments and if you have any amazing insights from your experience

The Power of the Paper Trail: Architecture Decision Records (ADRs)

Caleb Ariel — Fri, 13 Feb 2026 07:56:00 +0000

The ultimate output of knowledge work,in this case software architecture and engineering, is decision making. Regardless of what form it takes, recording the thought process of key decisions is an important part of maintaining clarity before, during and after decision are agreed upon, to help prevent hind-sight bias and to allow your future self and others, understand the environment in which the decisions were made.

In this post I will be sharing what I have been learning about Architecture Decision Records their applications in software and data projects.

What are ARDs anyway?

Architecture Decision Records are essentially a paper trail for significant architectural decisions that you make in the lifecyle of a project. I will mostly refer to them as ADRs from now on.

In my years as an software engineer and data engineer, I have scarcely, if at all come across this ADRs. Documentation has taken many forms in the projects I have been apart of; abandoned Notion pages, diagrams and sparsely detailed text files about what was going to be implemented or has already been implemented, or no documentation at all. When decison change, ADRs help track this by introducing states to these documents i.e Propose, Accepted, Rejected, Superseded

Why should you care?

Architectural decisions are some of the most costly in any organization. They have impacts on how easy it will be to add features or how resilient and flexible the system will be to changing requirements of the business. Interrogating and justifying these decisions with a decent amount of rigour, within the required time-frame becomes that much more important. Not to mention the framework can be adopting to many other fields and types of decision processes.

How do you know what to document?

Not every decision warrants a paper trail; the administrative overhead would be a nightmare. Michael Nygard describes "architecturally significant" decisions as those affecting:

Structure and construction techniques.
Non-functional characteristics, for example how it affects scalability or security.
Dependencies and interfaces

Ask yourself: Is this decision reversible, and what is the cost of reversing it?

Olaf Zimmermann goes into great detail on this in his blog post about what criteria to use. regarding decision criteria

Lightweight ADRs: Setting Them Up

I'll be the first to hold up a cross to administrative overhead and because gaining initial velocity on the habit of documentation is hard enough, lightweight ADRs make for the best format to help reap the benefits of documenting your decision without dramatically affecting your workflow.There are even tools that help you manage ADRs, which you can find in this gihub repo to help grease the wheels.

In my projects, I simply add an /adr folder consisting of one Markdown document per decision:

ADR 001 - Postgres for Operational Database.md
ADR 002 - Microservice Architecture for Orders Module.md

I include diagrams directly in the folder and commit everything to source control. This allows the documentation to version-match the code. When a decision changes, I don’t edit the old ADR; I create a new one, mark the old one as Superseded, and link to the replacement.

The lifecycle of ADRs

The lifecycle of these documents vary and are affected by team dynamics and roles and responsibilities of different stakeholder in the decision making process. There is always a main contact person or team responsible for communicating, publishing and maintaining these documents where maintenance is moving an adr from one state to the next.

I have come to interprete the states as below:

Proposed: The draft phase; getting stakeholders to poke holes in the logic.
Accepted: The green light; ensuring everyone is aligned on the path.
Rejected: Recording why we said "no" so we don't repeat the debate next year.
Superseded: Signaling that a new ADR has taken its place, ensuring there is only one "source of truth."

Conclusions

Documentation is a habit and one that is important especially with the changing landscape of tools and technologies that teams adopt. Though many of the organizational consideration that go into documentation frameworks haven't been touched on here, the rigour required to fill-in and socializing ADRs alone should help stave off some of the pitfalls that come with insufficient documentation and decision silos that are created as a result. Where ADRs live is just as important as writing them and it affects how they are versioned and maintained which is, in my opinion, the biggest battle with technical documentiation.

Resources:

More on ARDs and Templates.

References:

I am a junior data engineer without a senior engineer. What should I do?

Caleb Ariel — Mon, 30 Sep 2019 07:33:58 +0000

I am working at a startup and i was promoted to a junior data engineer a couple of months ago. This is my first rodeo with most things data engineering, coming from a dev background. I feel like I have too many blind spots and no one to help cover them.