Search for a command to run...
No comments yet. Be the first to comment.
This guide was initially generated using AI. Rather than writing every sentence from scratch, I used AI as a research, drafting and teaching assistant to help produce a comprehensive first draft. The
Modern dev environments rely heavily on third-party extensions. Many of these extensions execute code locally and may have access to source code, config files, credentials, and other sensitive data. A
A fresh Ubuntu installation is designed to be permissive, catering equally to desktop, server, and container workloads without assuming a strict security model. However, the moment a system is exposed
Developing software locally is only one part of the job. Systems must also operate reliably in production, handle failures, and remain maintainable as requirements change. A backend should be understa
Modern software systems power nearly every aspect of business operations, from banking platforms and healthcare systems to cloud infrastructure, e-commerce applications, and enterprise automation. As
With over eight years in the tech industry, I’ve learned a simple but uncomfortable truth. Effort compounds. The work you put in today pays off later in ways you cannot predict when you’re just starting out.
Credentials open doors. Consistent work determines progression.
Degrees, diplomas, and certifications have value, but it is limited. They may help your CV pass initial screening or get you into an interview. Beyond that, they carry little weight on their own.
Once you're in a conversation, the focus shifts to how you reason, how you approach problems, and what you've actually built. Without concrete work to reference, there is little to anchor that discussion, and that gap becomes visible quickly.
The job market is tough, and there’s no real bypass around that reality.
A common assumption, especially for graduates or career switchers is that companies will provide structured, in-depth training after hiring. In practice, that expectation often doesn’t match how teams operate.
Attitude does matter, but it has limited weight on its own. Intent is not a substitute for exposure, repetition, or hands-on experience with real systems.
From a hiring manager’s perspective, the role exists to offload execution so they can focus on higher-level work and system direction.
In that context, the expectation is rarely to onboard someone from zero. The preference is usually for someone who can contribute meaningfully within a short time frame, even if they're still growing in the role.
Support and guidance are part of the environment, but most positions assume a baseline of practical competence is already in place before day one.
If getting interviews or traction is difficult, relying only on qualifications on paper is often not enough. At some point, visibility and demonstrated ability start to matter more than listed credentials.
That visibility comes from consistent output. Whether through writing, short technical notes, videos, or documenting personal projects, the goal is the same: show how you think, how you approach problems, and how you communicate technical ideas.
Networking and public work are part of engineering practice as they surface how you think, communicate, and apply technical understanding in context that a CV alone cannot carry.
Whether the goal is a first role or progression within an existing one, the underlying principle stays consistent: make your work and reasoning visible.
At some point, self-assessment becomes necessary.
Would you hire yourself for this role, based on what you can demonstrate today?
If the answer is yes, there should be clear, practical reasons you can point to (work you’ve done, problems you’ve solved, and evidence of how you operate).
If your answer is no, then you’ve just identified a clear roadmap for your Tech Journey🙂
Hiring is centred on problem-solving capability. Stating that ability carries little weight on its own. What matters is showing how you approach problems, how you break them down, and whether you can carry that process through consistently.
In technical environments, documentation is a requirement of system longevity. People rotate, teams change, but the systems remain.
Good documentation reduces operational risk, improves maintainability, and lowers the cost of future change. The act of writing it also exposes gaps in understanding, making it a form of validation rather than just record-keeping.
Tip: If you are already in a role and want to remain effective over time, avoid outsourcing all reasoning to others. Asking questions is part of the workflow, but doing so without first attempting to understand the system yourself will eventually slow both learning and contribution.
Be careful not to confuse tenure with progression. Years of experience can accumulate without a corresponding increase in depth, ownership, or impact.
This often becomes visible when progression is expected but not granted. Being reliable within a defined scope is valuable, but it does not always translate into readiness for broader responsibility.
In many cases, the gap is not time spent in the industry, but the extent to which work has evolved in complexity, scope, and impact.
Over-reliance on AI to handle so-called tedious tasks can hide a deeper issue. Over time, people stop engaging directly with problems that once forced them to think critically and work through uncertainty. That kind of mental effort is what builds real technical strength.
AI is useful and should be part of the workflow, but as a support tool rather than a replacement for understanding. Every output still needs to be interpreted, validated, and understood in context. The reasoning behind a solution remains your responsibility, regardless of how it was produced.
Homelabbing since 2020 has made one thing clear: effective learning is not dependent on premium software or high-end hardware. Constraints often force a better understanding of fundamentals.
Free tiers and open-source tools are widely used in industry environments. They expose the same underlying concepts as enterprise platforms, which makes the skills transferable across stacks.
Tools such as Git, GitHub, Linux, Docker, Nginx, Python, Bash, Prometheus, Grafana, the ELK stack, n8n, Proxmox, and others can all be learned without financial cost. Some require account creation, while others can be installed and run locally for experimentation and practice.
The focus is not the tool itself, but the problem it solves and the system behaviour it represents.
At some point, planning stops being productive. Prolonged preparation without execution leads to stagnation while others gain experience through repetition and real work.
If there is intent to get serious about learning, it often requires practical trade-offs. That can include saving for an affordable, second-hand, upgradeable machine. Appearance is irrelevant. Stability and usability matter more than specifications or aesthetics.
Once a usable setup is in place, the workflow becomes straightforward: set up a lab, build and deploy something functional (don't worry about perfection), break it, recover it, and document the process. That cycle is where understanding develops.
NB: Avoid switching between tools or technologies without direction. Constantly chasing new stacks creates surface-level familiarity without depth. Sustained progress comes from selecting a small set of relevant tools and working with them long enough to understand their behaviour in real scenarios.
