Whether you're self-taught, vibe-coding, or coming into this fresh from a formal bootcamp or college course, you can grow your skills faster and build better applications if you avoid these mistakes and take some simple ideas on board.
Becoming a skilled software developer takes time, practice, and a willingness to learn from mistakes, but more than that it requires a different state of mind.
I often tell my programming students that I am a self-taught coder, but I learned how to be a software developer at college. By the end of this article you will understand exactly what I mean.
Do You Need Formal Education?
In the tech industry, there's a conflict between traditional computer science graduates and self-taught people.
Some hiring managers even worry that non-traditional developer journeys risk giving our profession a bad reputation.
My career has spanned several decades and I can tell you now I have met good and bad programmers from all backgrounds.
While there's some need for best practices, everyone starts somewhere, and I would suggest dogma, lack of self-awareness, and stubbornness are worse than learning from books and YouTube.
Here are the major issues I see evident in inexperienced programmers and what to do to improve.
1. Getting to "Done" ASAP
Many inexperienced developers are fixated on just getting code to run. Write code, compile/build/run, fix errors until it works, ship it.
Unless you are creating a throwaway utility for a one-off problem, Programming is more than just code.
Good software should be:
Readable and Maintainable: Well-written code is so clear it is self-evident how it works, what it is for, and why. Judicious use of comments helps elevate this code so anyone can take it and work with it. If necessary, of course, there should be documents too.
Scalable (within reason): One of the best things I ever did as a programmer was work with limited hardware such as computers from the 1970s and embedded/microcontroller systems. It teaches you how lazy and bloated modern software can be, but this has to be weighed against the first point, especially as not every system needs to shave microseconds off operations to be successful.
Secure: A major problem happening right now is AI-generated slop making end-users computers and devices less secure because vibe coders are not enough giving enough consideration or guard rails. A simple example can be cleverly illustrated with this XKCD cartoon.
User-friendly: Even if the user is you, why make future-you struggle to use the tool you created unnecessarily. User-friendly does not have to mean a fancy graphical user interface (GUI).
Appropriate for the task and the environment: What prompted this entire post was my friend vibe-coding a tool that the robot assumed would be a web app. Perhaps a web app is the correct approach, but think things through before building. What is the success criteria? Who is going to use the software? What will it need to integrate with? Who will maintain the software? Will it be multi-user? Does it need to maintain state/history/audit trail? What existing assets are available? What's the timeframe? ...
Elegant (again, within reason): One of the things you will hear a lot in programming is things like "Don't Repeat Yourself". Unfortunately, a lot of the AI tools did not get this memo. Especially when they run out of context window and get confused, poor things. Closely related, but more of a problem in advanced coders is "Not invented/built here" AKA "I am going to build my own solution because anything already available can never be as good as mine". Never let elegance be the enemy of maintainability though unless it absolutely must be that performant. 99% of projects are not in that category.
Basically don't let your code become a steaming hot mess that others (or even your future self) struggle to understand, maintain, or debug.
Before coding, ask questions and think:
Find out the what, why, how, when and who.
Break the big picture down into more addressable parts (eg. what are the inputs, the logic, any external elements, the outputs, etc).
Write down what each feature or task requires.
Analyse how your project or changes fit into the current codebase.
Think long-term.
2. Incremental Vs Big Releases
A lot of developers write huge chunks of code before testing. Not only is this overwhelming for anyone who is working with you, it also risks having a whole knot of issues to unravel if there is a problem.
Treat each independent feature, request, bug-fix as a discreet piece of work. By all mens fix all the typos in a document, but do not push both the database reorganisation and new search engine up together then wonder why you can't pin down which is causing the server to fall over.
Break your work into smaller, more digestible parts.
Each part should add one specific feature or fix.
Use feature branches. Commit frequently.
Test each piece individually to catch issues more easily.
3. Learning New Languages Instead of Principles
Developers have to be always learning because the field changes beneath us. Even COBOL programmers have had to learn new things over the years.
There is nothing wrong with learning new languages. My issue is when people hop from one shiny new language or framework to another, without learning any fundamental, underlying principles.
Mastering core programming concepts makes you a lot more valuable than having a bunch of thinly memorised dialects under your belt. Data structures, logic/conditionals, database management, algorithms, patterns, problem-solving strategies, and so on.
For example, it is a "tell" that a developer is either sloppy or experienced when all of their display or "rendering" code is interweaved in with their business logic and database queries, or when 80% of the code sits in one, huge nested "IF" statement subroutine.
4. Constant Task-Switching
I do not blame junior developers for this as it is more often the fault of bad leadership, but if you are not having massive amounts of task-switching imposed upon you then you are to blame.
Beginners try to work on several unrelated features, projects, or competing priorities at once, perhaps hoping to look busy or get validation, but end up not giving each task the thought, energy, time and care that they deserve.
Excessive multitasking will reduce the quality of your work and lead to burnout. It's better to focus on completing one task thoroughly. Whole-ass the thing instead of doing many tasks half-assed. Within the limits of your organisation culture and structure, of course.
Ask for a clear idea of priorities. Even if the boss can't or won't give you a good answer ("Everything is top priority" means nothing is a priority), it will indicate at least to yourself and your colleagues that the chaos is not of your own making.
5. Avoiding Feedback
I hate to be criticised but we all need it if we want to fully grow. "Code reviews" are essential for unearthing your knowledge holes, bad habits, or misunderstandings. It might be more comfortable and easier on the ego if they are left uncorrected, but long term you are doing yourself damage.
Seek feedback, make sure you understand critiques, and apply the advice as soon as you can.
Bottom Line
If you want to get good then you need to be willing to adjust and adopt more professional habits. I've been learning to code since the age of 8 with our Commodore Vic 20 and the bundled user guide.
I really learned to be a "software developer" by working in teams of programmers, and studying Cobol at night class and then Structured Systems Analysis and Design (SSADM) at college.
Coding is about inputting code and getting it to run, but if you want to develop good applications then your focus needs to expand to include writing clean, manageable, and well-thought-out systems that deliver on all fronts, not just error-message whack-a-mole.
Be patient with yourself, seek feedback, and focus on mastering core concepts. This will make you a more knowledgable, more reliable, and more capable developer, regardless of your background or the shiny new framework of the week.