Advice I Often Give to Young Developers
A young developer I work with recently asked me how to become more effective in this job. His question reminded me of many similar conversations with students, collaborators, and early-career engineers. This note preserves the core advice I gave him.
Why This Note
There are questions that return so often that they become part of one's teaching and mentoring life. How can I become better at this job? How can I deliver features faster? How do I use AI without becoming dependent on it? How do I stay reliable when deadlines, clients, code quality, and uncertainty all collide?
A few weeks ago, a young developer with whom I work asked me a version of that question. I answered him through a series of voice notes. When I listened back to the discussion, I realized that the advice was not only for him. It was the same set of principles I often share with my students and collaborators: simple, practical ideas that help a developer become more trustworthy, more autonomous, and more useful in real projects.
The Central Idea
My central point is this: a developer's effectiveness does not come first from tools, frameworks, or even artificial intelligence. It comes from two deeper habits: a healthy mindset and a disciplined way of organizing work. AI becomes powerful when it amplifies a clear intention, a well-framed problem, and a thoughtful execution plan. If the intention is confused, AI mainly helps produce confusion faster.
This is why I do not reduce professional growth to learning more commands, installing more extensions, or chasing every new technology. Those things can help, but they are secondary. The more fundamental question is whether people can trust your trajectory: what you accepted, how you planned it, how you reasoned about it, how you communicated when things changed, and what you finally delivered.
| Principle | Practical meaning |
|---|---|
| Be honest before accepting work | Know your rhythm, your constraints, and the real effort required. |
| Plan before execution | Decide when and how you will work before sitting down to code. |
| Think before coding | Clarify the need, the rules, the edge cases, and the definition of done. |
| Use AI deliberately | Give context, constraints, examples, and a plan before asking for code. |
| Deliver in increments | Ship the smallest useful version, then improve without losing readability. |
| Communicate early | Signal blockers, limits, trade-offs, and changes in direction before trust is damaged. |
1. Do Not Accept More Than You Can Really Do
The first professional skill is honesty. Before saying yes to a task, a developer should ask: Can I really do this in the requested time? Under what conditions can I work well? What usually slows me down? What should I say clearly from the beginning? Reliability starts before the first line of code.
Saying early I can do it, I cannot do it, or I can do it, but not within that deadline is not weakness. It is a sign of maturity. Many professional problems are not caused by technical failure alone; they come from vague commitments that nobody dared to clarify in time.
2. Think Before Coding
When I enter a project or take a ticket, I first try to understand the basic definitions. This is probably my mathematician's reflex: if you do not know the axioms, you cannot reason properly. What are we trying to build? How should it behave? Which rules are mandatory? Which cases are exceptions? What will make us say that the task is finished?
Thinking can feel slow because nothing visible is being produced yet. But in software, unclear thinking is expensive. It often leads to empirical coding, confused refactoring, and avoidable frustration. Time spent understanding the problem usually reduces the total time required to deliver the solution.
3. Use AI as an Accelerator, Not as a Pilot
AI tools can save a lot of time, but they work best when the developer already knows what they want. Before asking an AI system to produce code, documentation, tests, or a refactor, give it context, the expected result, the constraints, the preferred output format, the steps of the plan, and examples or edge cases.
The model matters less than the clarity of the design. A good prompt cannot replace judgment; it expresses judgment. This is the difference between delegating execution and outsourcing thinking. A young developer should learn to use AI to generate, compare, test, document, and accelerate, but not to avoid understanding.
4. Deliver in Useful Increments
Real projects require balance: deadline, quality, and the needs of the person or organization in front of you. Sometimes the right decision is not to build the perfect architecture immediately. It may be better to deliver a readable first version that creates value, then improve the structure afterward.
Incremental delivery does not mean careless work. It means choosing the right level of quality at the right time. Readability should remain non-negotiable, because today's temporary code often becomes tomorrow's foundation. But a useful version delivered in time can create trust, feedback, and momentum.
5. Avoid Tool Obsession and Overengineering
A developer does not need to become an expert in every tool or every possible configuration. Keep your environment simple. Learn advanced setups when they answer a real problem, not because they look sophisticated. The same applies to architecture: do not build today every feature that might perhaps be useful tomorrow.
I often use a simple image: if you are building a hotel and the clients do not yet need a swimming pool, do not begin by building the pool. Keep in mind that it may become useful later, and leave room for evolution, but do not pay the full cost too early.
6. Communicate Before Trust Breaks
Delays, errors, and failures happen. What damages trust most is not always the failure itself; it is the fog around the failure. When something cannot be done, say it early, explain why, propose an alternative if possible, and accept the consequences without turning every disagreement into a personal conflict.
A reliable developer is not someone who succeeds at everything. A reliable developer is someone whose decisions can be understood. People can work with you when your path is visible: what you tried, what changed, what remains possible, and what you recommend next.
A Practical Checklist for Young Developers
- Before starting: reformulate the need in one sentence, list the business rules and edge cases, estimate the time, and define the smallest useful increment.
- During the work: understand before coding, use AI to support your plan, keep the code readable, and check regularly whether the deadline and quality level still make sense.
- After delivery: note what slowed you down, identify what could be automated next time, refactor what will serve future work, and turn the experience into a working rule.
If I had to compress everything into one formula, it would be this: understand before coding; plan before executing; deliver small but useful; remain readable; communicate early; use AI as an accelerator, not as the pilot.