What I would do today if you started again from scratch as a developer

I can help you with that. However, I don't see the Italian text provided. Please paste the Italian text, and I'll be happy to assist you in translating it into English while following the given rules.

Starting from scratch is a mental exercise that every developer does at least once, usually at a point in their career where they look back and can clearly see the detours, blind alleys, time spent on things that didn't serve them, and the time not spent on things that would have helped much earlier. It's an honest exercise and sometimes uncomfortable - but it's also one of the most useful tools for understanding what really matters.

This article is the answer to the question: if I woke up tomorrow morning without any of the tech skills I have now, knowing what I know now, what would I do? I don't have the perfect answer - that one doesn't exist. I have the most honest answer I can give, based on what I've observed consistently work in both my journey and that of many other developers I've crossed paths with over time.

The premise of this article is different from that of the previous one. The second article in the series was retrospective: "what I would have wanted to know". This is prospective: "what I would do". The difference is that here there are choices and concrete actions, not just awareness. Each section of this article contains at least one operational decision - something you can do, not just think.

If you've already read the two previous articles in this series, some of the topics here will resonate with you. I won't repeat them in detail - instead, I'll translate them into concrete steps. The thread is always the same: the path from background non-CS to developer is not a random journey. It has a structure. That structure can be learned.

A preface on timing: the article discusses a 12-month journey, but for many people, the actual path is longer - especially if they're not studying full-time. If you study 2 hours a day alongside an existing job, the 12 months of the plan become 18-24 months. It's not a failure - it's math. The plan is scalable: phases remain the same, durations stretch in proportion to available time. What's important is not compressing phases by eliminating practice - which is the most common way the plan falls apart. You can extend the time, but you cannot skip practice.

Typical difficulties

The difficulties in planning a comeback journey are not only practical - they are also cognitive. The way you think about the journey influences what you do.

The false choice between theory and practice

One of the most frequent tensions for those who are starting out is the question: do I need to learn theory (algorithms, data structures, fundamental computer science) first or practice (building something that works, even with theoretical gaps)? The right answer is: both, in sequence and integrated - not as an alternative. Theory without practice produces abstract knowledge that doesn't solidify. Practice without theory produces code that works but doesn't understand enough to be modified or extended.

The optimal balance changes based on objectives: those who want to find work in the short term have an incentive to weigh more towards practice (portfolio, deployed projects) because the junior job market values that. Those who want to build solid competence in the long term have an incentive not to sacrifice the foundation. The way to do both without going crazy is to alternate: one week focused on foundations, one with focus on practical project.

Path option parallelism

Another difficulty is the simultaneity of possible paths. Frontend, Backend, Full-stack, Data Engineering, AI Engineering, DevOps - all seem possible and none seems definitive. The temptation is to study a little bit of everything to have options. The result, almost invariably, is arriving at the job market without a clear vertical competence in anything.

The way to get out of this parallelism is not to choose "forever" - that choice doesn't exist in tech, where trajectories change often. It's to choose "for the next 18 months" with the intention of revisiting the decision afterwards. This distinction reduces the pressure of making a decision without eliminating the need to do so.

A useful metaphor is choosing a technical path as choosing a language to learn. The choice of learning Spanish does not exclude the possibility of also learning French in the future - but if you try to learn Spanish and French and German simultaneously with the same level of intensity, you will end up speaking poorly at none of the three. The second language learns much more quickly after having built fluency in the first. The same applies to technical paths: choose one, build fluency, then expand.

The information dissemination of training

The tech training market is one of the most saturated out there. There are literally tens of thousands of courses, bootcamps, books, tutorials, YouTube channels, newsletters, and communities. In this scenario, the ability to filter and ignore is more valuable than the ability to find. 95% of available resources are redundant with only 5% that really matters. The time spent evaluating extra resources is taken away from executing the chosen resources.

One of the patterns I've observed most frequently is "tutorial hopping": passing from one tutorial to another without completing any, with the justification that you're looking for "the right one". The right tutorial almost always doesn't exist in absolute terms - there's a good enough tutorial that you end up with it. Completing a mediocre tutorial yields more learning than starting ten excellent ones.

The disconnection between study and portfolio

Another difficulty I often observe: who studies for months without building anything public, accumulating theoretical knowledge without producing concrete evidence. The disconnection between study and portfolio arises from the idea that the portfolio comes "after" - after you're good enough, after you've finished your curriculum, after you feel ready. But you never feel ready until you already have something public that works. Waiting produces a vicious cycle that breaks only by building something - even imperfect, even small - and publishing it.

Your portfolio is not a demonstration that you have finished learning. It's the real-time tracker of where you are on your journey. A portfolio with 5 small projects that grows over time tells a story of growth. A portfolio with zero projects until you're "ready" doesn't tell anything, because the moment when you're ready never arrives by definition.

What worked (Federico)

This is the heart of the article. It's not a generic roadmap - it's what I would do myself, in this order, starting from scratch today.

Week 0: choose the vertical path

Before opening any editor, I would define the path. Not "I want to be a developer" - "I want to be a Frontend Developer / Backend Developer / Data Engineer". The choice of path determines the curriculum, resources, portfolio, and interviews. Having made this choice, all subsequent decisions become simpler because there is a criterion: "This serves for my path? Yes → proceed. No → ignore."

How to choose? The most practical way I know is to look roadmap.sh, che raccoglie roadmap curate per ogni percorso tech, e leggere le prime 3-4 settimane di ciascuno dei percorsi che mi sembrano interessanti. Quello che leggo con più curiosità e meno fatica è probabilmente il segnale più onesto di dove investire tempo. Non è un criterio infallibile - ci sono percorsi che sembrano interessanti e poi si rivelano meno adatti, e percorsi che sembrano difficili all'inizio e poi diventano i più adatti. Ma è un punto di partenza sufficientemente buono per iniziare a muoversi.

Months 1-2: foundation + first language

The first two months I would spend on two resources in parallel: Harvard CS50 for the fundamental concepts and freeCodeCamp For practical application. CS50 gives the "why" - how a computer works, what an algorithm is, what data structures are. freeCodeCamp gives the "how" - syntax, patterns, projects.

The first language I would focus on depends on the chosen path: JavaScript for Frontend and Full-stack, Python for Backend and AI, Go or Java for Enterprise Backend. I wouldn't change languages during the first two months - the risk is using a language change as a procrastination tactic disguised as a strategy.

Month 3: first public project

By the third month I will build my first public project on GitHub. Not the best project - the first one. Something small that solves a real problem, even an ordinary one: a unit converter, a password generator, a simple static blog. The minimum requirement is that it be deployed online (GitHub Pages is free for static sites) and that the code be public.

The reason for starting so early with a public project isn't the quality of the project - it will inevitably be imperfect. It's the habit: building something, making it work, publishing it, moving on to the next one. This habit naturally produces a portfolio over time without having to do a "portfolio project" special at the end of training.

Months 4-8: technical vertical + portfolio 3-5 projects

central months, focus would be on verticalization in the chosen path: main frameworks (React/Angular for Frontend, Spring Boot/FastAPI for Backend, dbt/Spark for Data), databases (SQL is mandatory for all paths, like a second step), professional Git workflow (feature branches, pull requests, code reviews). In parallel, I would bring my portfolio from 1 to 3-5 high-quality projects.

The rule for portfolio projects I learned: every project must answer two questions. First: does it solve a real problem, even a small one? Second: is the code readable by someone who did not write it? If the answer to both is yes, the project is suitable for the portfolio. If the answer is no to either, it needs to be improved before being shown.

Months 9-12: looking for work as a second job

After 8-9 months of serious study, start looking for an active job - not after finishing the training, because training never ends. The process of finding a job for a junior developer requires on average 3-6 months in the Italian market. Starting at month 9 means that there's a significant chance of being hired around month 12-15. Starting at month 18 moves everything back by 9 months without a valid technical reason.

I treat job searching as a second job: 2-3 hours a day, with metrics tracked (applications submitted, responses received, interviews, offers), with iteration based on feedback. The feedback from interviews - even the ones that didn't go well - are valuable insights on where to focus your study for the next few weeks.

Throughout the entire journey: active network but calibrated.

Something I would do from the start, not as a separate phase but as an ongoing parallel practice, is to build a minimal yet active online presence. Not a sophisticated personal branding strategy - something simple: an up-to-date GitHub profile, some comments on DEV.to or Stack Overflow about topics I'm studying, occasional participation in Italian developer communities (GitBar has a Slack community, there are local meetups in many cities).

The reason to start soon is not the short-term visibility - that's negligible at first. It's habit. Whoever starts participating in the community right away, even in a minimal way, has a concrete advantage when starting the job search: they already have a network, no matter how small it is. Whoever starts only when looking for work begins from scratch in an instant where they already have many other priorities.

The time to invest in this dimension is small: 15-20 minutes a day, no more. The goal is not to become a tech influencer - it's to be present in the conversation of the sector, even as an early listener.

8. Preparation for the technical meeting: start early

One of the things I would do differently than my path is to start preparing for technical interviews much earlier than it seems necessary. The technical interview for a junior role is an algorithm and data structure exam - content that in bootcamps and online resumes are often treated superficially, whereas they are the main focus of the selection process at structured interview- conducting companies.

The standard resource for this preparation is Note: I've kept the original formatting and punctuation, including the token XPHX0XPHX and XPHX1XPHX. Let me know if you need any further assistance! Cracking the Coding Interview 1. Le regole del gioco 2. Come vincere 3. I concorrenti 4. Il giudice 5. La vittoria 6. L'esperienza By Gayle Laakmann McDowell (ISBN 978-0984782857), but the book alone is not enough - it needs to be integrated with practice on platforms like LeetCode or HackerRank. I would do 1-2 problems a day starting from month 5-6, not wait until month 9-10. Doing two problems a day for three months produces approximately 180-200 solved problems - which is a solid foundation for most junior interviews.

Cognitive framework

Two mental frameworks that I would use from the start, not just as philosophy but as practical tools for decision-making.

Deep Work as a study method (Newport)

Cal Newport in Deep Work Il lavoro profondo (Deep Work) è un concetto che si riferisce alla concentrazione assoluta e senza distrazioni su una singola attività. È stato sviluppato da Cal Newport, professore di ingegneria presso l'Università del Texas a Austin. Il lavoro profondo è caratterizzato dalla presenza di tre elementi fondamentali: 1. **Concentrazione assoluta**: il lavoratore deve essere completamente impegnato nella sua attività e non avere alcuna distrazione. 2. **Assenza di distrazioni**: il lavoratore deve eliminare tutte le fonti di distrazione, come ad esempio i social media o la posta elettronica. 3. **Miglioramento della produttività**: il lavoro profondo è progettato per migliorare la produttività del lavoratore. Il lavoro profondo è spesso contrapposto al "lavoro superficiale", che consiste nell'essere sempre "presenti" e "attivi" anche quando non si sta lavorando. (ISBN 978-1455586691) distinguishes between deep work - intense concentration on cognitively challenging problems, without distractions - and superficial work - fragmented tasks, emails, notifications, multitasking. The economic value of deep work is high and growing. The ability to do it is rare and deteriorates if not trained.

Applied to technical study, this means: study sessions without phone, without notifications, without social media. Not 20 minutes between distractions - 60-90 minutes of dense cognitive work on a specific problem. Performance so far is incomparably superior. If I had to start again, I would begin practicing this modality from day one - I wouldn't wait for "more time".

The spaced repetition review system

A practical framework that I would immediately integrate is spaced repetition for technical concepts. Every new concept I encounter - a programming pattern, a library function, a Git command - goes into a revision system (Anki is free) with two versions: the question and the answer. The review takes place at increasingly longer intervals over time. The result is that the concepts I use less frequently remain accessible, rather than disappearing from active memory.

It seems like an excessive overhead at the beginning. It's not. The time invested in creating cards is repaid every time you remember something that would have otherwise had to be searched for again. The compounding of memory is just as real as the compounding of daily habits.

The principle of the 80/20 applied to technical study

A framework I would have liked to know about earlier is the Pareto principle applied to technical learning: 80% of problems you will encounter in real work are solved with 20% of available theoretical knowledge. This does not mean that the remaining 80% is useless - it means there is an order of priority in acquiring knowledge, and studying the most used things before the less used ones is a rational strategy.

For the Frontend Developer, the top 20% of skills is: Semantic HTML, CSS layout (Flexbox + Grid), Asynchronous JavaScript (Promises + async/await), a main library or framework (React or Angular), and the Git base cycle (commit, push, pull, merge). With these knowledge, you solve 80% of problems in your daily work as a junior. The rest - Advanced TypeScript, performance optimization, complex architecture, advanced testing - is added progressively with work experience, not necessarily beforehand.

Practical implication: stop studying advanced topics until you master the basics. The temptation to skip over "cool" technologies - GraphQL, WebAssembly, microservices - when you still struggle with state management in React is a form of technical procrastination. Depth comes before breadth, not the other way around.

Readings and Resources

These are the resources I would use, in this order, if you were to start again from scratch. It's not an exhaustive list - it's a minimal one that covers the real needs of the early stages.

Structured Resources for the First 6 Months

• roadmap.sh First step: choose the path, read the extended roadmap, identify the first 10 milestones. It's not a resume – it's a map. Use it as guidance, not a strict checklist to follow letter for letter.
• Harvard CS50 Foundational concepts. Months 1-2, parallel to applied practice. The time cost is 10-15 hours total for main readings - the return is an understanding of the foundations that lasts years.
• freeCodeCamp Practical curriculum for months 1-4. Choose the corresponding path according to your level. Do everything - don't skip the modules that seem trivial.

Foundational Books

• Cal Newport, Deep Work Il lavoro profondo (Deep Work) è un concetto che si riferisce alla concentrazione assoluta e senza distrazioni su una singola attività. È stato sviluppato da Cal Newport, professore di ingegneria presso l'Università del Texas a Austin. Il lavoro profondo è caratterizzato dalla presenza di tre elementi fondamentali: 1. **Concentrazione assoluta**: il lavoratore deve essere completamente impegnato nella sua attività e non avere alcuna distrazione. 2. **Assenza di distrazioni**: il lavoratore deve eliminare tutte le fonti di distrazione, come ad esempio i social media o la posta elettronica. 3. **Miglioramento della produttività**: il lavoro profondo è progettato per migliorare la produttività del lavoratore. Il lavoro profondo è spesso contrapposto al "lavoro superficiale", che consiste nell'essere sempre "presenti" e "attivi" anche quando non si sta lavorando. ISBN 978-1455586691 - Technical study requires deep concentration. This book teaches how to cultivate it. Read before starting, not after.
• Andrew Hunt and David Thomas, Il Programmatore Pragmatico ISBN 978-0135957059 - The Developer Professional's Handbook. Does not replace technical learning, but rather guides it. A chapter per week while you progress through your resume.

The Study Guide 6 months that I prepared is the detailed weekly plan, week by week of what I would do - with specific resources for each week and self-assessment checkpoints. That's what I wanted to have at the beginning. You can download it for free here above.

Resources for preparing for interviews

• Gayle Laakmann McDowell, Cracking the Coding Interview 1. Le regole del gioco 2. Come vincere 3. I concorrenti 4. Il giudice 5. La vittoria 6. L'esperienza (ISBN 978-0984782857) - The standard reference for technical interview preparation. It is not to be read from start to finish like a book - it is meant to be used as a workbook, doing the problems and checking the solutions.
• LeetCode The platform for practicing algorithms and data structures. Start with the "Easy" section - problems in the "Hard" section can wait until you have a solid foundation in "Easy" and "Medium".

Next step in the series

Tuesday next week the fourth article of the series will be released: My biggest mistake after graduation CS (and what I learned)I am still an article narrator, but with a specific focus on errors - not as a confession, but as a source of data. Errors tell us where expectations were out of calibration, and those expectations are often the same for everyone, regardless of their background.

If you have arrived at this article, you have already read three parts of the series. Each article is autonomous - you can read one without the others. But sequential reading creates a narrative thread that makes sense: from why (the impostor syndrome) to what (what to know) to action (what to do).

You can find all articles in the series on cornerstone of the seriesWhere there is also a complete career matrix with 12 paths and downloadable lead magnets.

See also: What I would have liked to know when I started programming The second article of the series, complementary to this.

What I have learned writing this

Writing this article was an exercise in forced synthesis. The problem wasn't finding the content - it was cutting. I wrote and rewrote the "What worked for me" section four times, each time removing something that in hindsight seemed obvious or overlapped with things already said in the two previous articles in the series.

One thing I've understood in the process is that there's a difference between what worked for me and what would work for me if I were to start again now. It's not the same list. Resources change, opportunities change, best practices change. What remains constant is the structure: foundation before advanced practice, public project before looking for work, technical vertical clear before generalism. On these principles I have more confidence.

I've also noticed that the parts of the article I found most difficult to write are those with stronger advice - "just stop doing this and start doing that." The prescriptive tone is uncomfortable when writing in first person, because every person has their own context. The solution I found is always to filter through "this is what I would do" - not "this is what you should do." The difference is small in the text, but it's huge in terms of responsibility for making a declaration.

One thing I took away from an earlier version of this article: a section on motivation. I had written it as the third cognitive framework - how to maintain motivation over the long period when progress is slow and results aren't immediate. I decided to remove it because it's not the type of problem that can be solved with a framework. Motivation is maintained by building working things, seeing concrete progress, having a network of people who are going through the same journey. It doesn't solve with an article explaining how to maintain it. The best advice on motivation is: build your first public thing as soon as possible, and let concrete evidence do its job.

One thing I added instead of the first draft is the section on preparing for technical interviews. I was afraid it would seem too "mechanical" - as if reducing job search to numbers and metrics took away something human from the process. Then I thought about it, and decided to keep it because it's honest. The technical interview is a specific skill that trains, not an exam on the "goodness" of the developer. Treating it as a specific skill - with deliberate practice, feedback, iteration - is respectful towards oneself, not the opposite.

If you're planning to start again - whether from scratch or with partial training - I'd love to know where you are now and what's holding you back. Not to give you pre-made answers, but because specific questions help me understand if the articles I write address real problems. Write to Federico at federicocalo.dev.

I'll respond. Always.

If you are starting to use tools like Claude Code to compensate for the formal training gap, I have collected a series dedicated to the workflow agent that I use daily on my portfolio: Claude Code Workflow: Superpowers + GSD FrameworkIt's the system that allows me to manage 19 parallel phases without a development team behind it.