1w ago

How to become a competent coder?

I would like to code for a living and to contribute to open source projects and things, but my coding skills are absolute shit after taking online courses and watching video tutorials. How can I learn to code for real?

What I would like to learn is algorithms, web development ("full stack"), how layouts work (both in like kotlin compose and HTML) and how to read other peoples code. Maybe thats more than I can chew, but its probably good for me to try out many things before getting settled on one.

Now I have been coding for a while already (~ 4 years), but I kind of feel like I need more guidance to be able to actually create code that works as intended intentionally, and not through trial and error / stack overflow. As for what level i am at, CS50 is probably my only qualification, I have played around with APIs (I.E. making discord bots), and made some html "apps" (horribly made, but things like the "genius" game and a calculator) and "prototype" react websites (as in, really bare bones, barely working).

I do plan on taking CS or something similar, but i'm not yet in college, and I would like to have a good head start before getting there.

Sorry for my bad English, and any help is appreciated.

37 comments

Practice. Write bad code, come back later and rewrite it. Repeat.
- I would also add that one of the best experiences one can have is to have to maintain one's own code - coming back 6 months or a year later (long enough to have forgotten the details of it) to the code one has made to add new features is quite the eye opener and a serious incentive for improving the quality of one's coding because now you're being burned from all the stupid lazy choices if your past self and also spotting things you did not know were important and whose full impact you were not aware of.
  I've crossed paths with people who for one reason or another only ever did brand new programs from the ground up and their code tends to be messy, hard to understand and prone to break in unexpected ways and places when people try to add or change features in it.
  
  Yup, exactly. And rereading your own code also gives good appreciation for how code should be commented, because even if I understand the code itself, the "why" is often lost to time.

Books are always a good source. And they're structured and teach stuff in the correct order. Something stackoverflow and the internet doesn't do. So if you can find proper books on the programming languages and frameworks you're interested in, I'd recommend to read those. And keep in mind there are libraries, if you don't want to buy books and they're not available online. Though, if it's a niche topic, it'd have to be more a university library than a public one. It's worth a try. Otherwise, you can always buy them. Just have a (quick) look at the content first, so it matches your interest and level of prior knowledge.
- Wisdom that was shared with me: the first step to becoming a great coder is becoming a shitty coder.

To me, what sets apart good coders from mediocre ones is one thing: understanding why we do things. Don't just implement the thing because that's the task. Understand why it's required and your implementation will be better. Don't blindly follow best practices. Understand why they are best practices and when they apply. Understand what's going on rather than just do what you're told (but probably also do what you're told if you want to keep your job).
I know people who have been at it for many years and they don't understand why we do things this or that way, they just know that's how we should do it.
- This, this is it, right here. I can't tell you the amount of times I wanted to smash a coworker head against the table because they were doing stuff the way it was "supposed" to be done without understanding the reason. For example at one job I worked doing rebases on git was prohibited, everyone knew it was a rule, everyone respected it, I kept asking why but no one had an answer, until at one point I was chatting with a senior architect and I asked him and he said "oh, it's not prohibited, it's just that someone messed up a repo trying to do a rebase once so we told them not to rebase unless you knew what you were doing". And just like that there were thousands of other things that made me realize that most programmers just accept things as they are instead of trying to understand why, which causes several problems, the most common one being the XY problem.
  
  I had the exact same experience when starting a new job. The team had very strict rules that absolutely could not be broken. When I finally asked an architect he said the same thing: it's just a general guideline, but of course if it makes more sense to deviate, then by all means.
  They fostered this culture because they mostly had junior programmers, but they never evolved beyond that because they were taught "good code" but never learned why it's good code.
- Adding to your advice: RTFM. I have been a professional developer for more than 20 years and the number of people i have worked with, who bothered to read the manual, can be counted on one hand. So many bugs can be avoided if people bothered to read the manual for whatever software/SDK they are using.
  
  Jeezus, you're not kidding. I've been in the industry for more than a decade. Everything I write I make sure is covered by documentation in detail. Never know when I'll be unavailable to address something that pops up. I get pings daily with people asking me how to do X with Y system, even on vacations. I've gotten into the habit of just sending them a link to the documentation that explains what they're looking for. I get not wanting to sort through piles of documentation for a small thing, but holy hell it gets exhausting after a while. If people would even skim the manuals they'd have an idea of what and where to find stuff. Don't know why I even bother half the time if nobody is going to read it.

First off, the fact that you are aware of your shortcomings and are interested in addressing them is awesome. That shows real growth potential and wisdom.
I'm no rockstar developer, but I've been doing it professionally for over 2 decades. And I've been told by multiple bosses that I'm pretty good at my job. I've worked with a lot of other developers. Including some less experienced ones. Here are some thoughts on pitfalls and hurdles I've seen, both in myself and truth other developers:
Don't get too fixated on the technology. I know that sounds weird at first blush, but there's a whole layer to software development that involves analysis and critical thinking, and that layer is completely agnostic of technology. Make sure you work on your analytical skills, because they are the foundation that will allow you to excel with actually writing code.
Sometimes newer isn't better. It's tempting to chase after the latest approach or platform and think that will be perfect and last for many years to come. But they seldom last more than 5 years before they start getting vilified as old and outdated. Yet there's a lot of wisdom and tried-and-tested reliability in older approaches and seemingly stale design patterns.
Related to that, many of the concepts in software development are cyclical to a degree. What's considered passe and wrong today can often be returned under a cool new name in 5 or 10 years time and suddenly find popularity and use again. So be prepared for that.
Get to know design patterns, but don't treat them as set in stone. Two mistakes I've seen people do (and I've done myself) is assume a) a design pattern fits into more scenarios than are actually applicable, and b) think that design patterns are immutable and must be followed completely. But really they are like a buffet where you can take often a bite or two from one, and where also every trip to the restaurant is different, so your menu of choice will change.
Practice software development from the ground up. Where the ground is reading business requirements, then converting them to system requirements, then designing your a system, then implementing it, and then working through the subsequent challenges.
Related to that, it's extremely rare that a developer creates a complex system with perfect code right out the gate. It's okay to make mistakes and work around them. It's just part of the process and something we all do.
Don't get too caught up on writing code "the right way". I think coding is more an art than a science. And with that in mind, have some fun with it. Keep in mind things like performance and scalability, obviously. But if you stick to a rigid approach to writing code you will struggle to evolve and adapt and build your skill set.
Also, I bet you are a better coder than you think. So many developers I've worked with think they are poor at writing code and have imposter syndrome. But most of them are solid.
And lastly, in my opinion don't get caught up on certifications. I've worked with devs who had lots of certificates and who were okay. But I've also worked with devs who had no formal training and no certificates, but they were amazing at writing really innovative, well designed, and high performing code. Like I said earlier, it's all about the state of mind.
Hope this helps.
Edit: fixed some typos.
- I agree, though I'd like to add that it really helps to learn it properly. I've also met people who learned everything by themselves in an unstructured way, and sometimes they struggle with the underlying concepts. And yes, it's art. But sometimes you want your customer data not to be stolen, and your software not to have any bugs and leaks. I think sometimes it't that kind of art that requires effort, dedication and deep knowledge about a topic.
  It's really fun though, at least in my opinion. And it's a broad field. Some software needs mathematical precision and be provable and secure, other things are more design, there's so many different things...
  Yeah and I agree, you can just try lots if things on a computer, and if it's not right, you just correct it. Mistakes are cheap while learning... And that's not the case in other professions. So you can just try and figure out things pretty much as you like.
- Thank you for the response, I actually was with the opposite position as to being an art. I was literally just thinking "there is a correct way to do things, if you don't use it, your code sucks", and things like that. (Im watching a Linus Torvalds interview, and he was just talking about good vs bad code lol).

Here's what I look for with software engineers II hire.
Pragmatism: pick the right solution for the right problem. And your work should create minimal work for others.
Thirst to learn: there is always something new and exciting and there's always a better way to do it. Look for that. It also means being open to feedback.
Collaboration instead of execution: I need my team to challenge me. For that, they need to get as much of the bigger picture as they can. That means always being able to answer "why" you do things. It also means that I expect healthy conflict with my teams. If you go from being taught to teaching me, you immediately get a bump in my list of top teammates.
No excuse: we acknowledge problems and deal with them together. (Requires a good work environment though).
As you can see, nothing I wrote is purely code related. Only thing I ask tech wise is: know your shit, where to find it, who to ask.
Also, my top resource to get people started with what it means to become a software engineer is solidbook.io.

Same as anything else, hours of practice

The obvious answer is to jump in and actually code something you want to use yourself. It will be fun, right?
I must admit that this kind of question always baffles me a bit. Why would anyone want to do boring courses and video tutorials when they can just get started on a real problem and learn as they go? There's nothing more dull than solving a fake problem.
Unless - unless! - it's that really you're interested in the status and money that comes with coding rather than the coding itself. In which case go ahead and get lots of paper qualifications and jump thru hoops to polish up that CV etc etc. But be prepared for a boring career.
- I agree with you, but maybe my problem is that I cannot focus on something long enough? I have started probably ~100 projects that would all be "the one that is for real", and never ended any. What I said about having coded for many years but not having many qualifications is exactly that, I have coded in probably 10+ languages, all of them very badly and unfocused.
  Right now I am working in a project for my brother (he doesn't really need it, but it would be a nice plus), that is basically a flask web app where he can keep track of AV equipment. It is quite basic really, but not having the prior knowledge of how to structure divs and such (compositing / layouts), I really struggle to create a UI, so I just start copy pasting from the bootstrap documentation...
  Maybe I should just double down on what I have been doing tho.
  Thanks for the answer :)
  
  You are never wasting your time with unfinished projects no matter how unrelated it might seem to your current interests.
  You dont have the right mindset yet to push through and finish a project, mostly because of poor ideation of the full project, rather than how things get done logically on your code.
  You dont need to just be a developer, you are a professional problem solver of all kinds and any obstacle can get absolutely FUCKED if it thinks its going to keep you from getting to the next step.
  Project management is important and theres a free textbook link below, but working alone and without a bugdet or real time constraints gives you the freedom to work on any aspect of a project as you feel like it... and can switch between focuses so you can dream about how users will interact with your project, or what algorithm could solve a specific problem in the project. The key is to write (type) everything down and don't stop. And you really dont even want to be coding at this point... just pseudo code... class diagrams... different visualizations.
  And hey if you burn out and lose focus, you identified what you need to learn and maybe even have something to show for it. Yes minimizing these slips gets easier but once you start going through the complex motions of realistic projects you will eventually start memorizing.
  https://pressbooks.ulib.csuohio.edu/project-management-navigating-the-complexity/
  
  Probably focus on finishing a project. I myself have a graveyard of unfinished shit but it’s not a great look if you’ve never finished something.
  Starting a project is always the fun part but if you quit something the second you hit a wall you won’t be pushing yourself to actually learn. You also probably wouldn’t be much use to someone trying to maintain and develop their project.
  I was a dev for ten+ years then pivoted to pm during Covid

Simple. Time, exposure, experience.
Write a lot of code, ask a lot of “why” questions, review a lot of peer and senior code. Don’t settle for “it works”, make an effort to be proud of your code, going the extra mile to ensure it is readable, scalable, optimal. Rewriting and refactoring are also good challenges and tools for honing these things.
Also… you’re not even in college yet, so you’re way ahead of the game. Stay the course, get proper education from an accredited program and you’ll be just fine.

Read other people's code. Dig through source code of libraries you use. You don't have to understand their entire stack, but you'll start to see all sorts of skill levels in production code. This obviously comes with the requirement to have some basic experience to comprehend the fundamentals of coding.
I've been a professional web dev for over 15 years and when I'm feeling down about my code, I just look through WordPress plugin source code. I've seen clients use some terribly coded plugins with a $50/mo price tag on them. No one cares.
But every once and a while, you'll come across something beautiful, something thar will inspire you in just the right way and it'll click how to code something. It can even be just a small portion of a messy project, but learn to recognize when you're writing good code and be proud of that. Also learn to sometimes accept messy code.
Did I ship high quality code for every project last year? Hell. No. Some clients have smaller budgets or there isn't time to work out the most elegant solutions or there's pressures to ship ASAP. But there were a few projects I was given the time and space to write some code I'm genuinely proud of.
I've been in the industry long enough to know that skill and ability doesn't hold back as many people back as you'd expect. Do I want more under skilled coders entering the industry? not really, but we all have to start somewhere. And as long as there is progress being made, it'll be fine.
I wasn't skilled or even a coder when I first started out (I was an art major) I lied and learned it all in the job. The web dev ecosystem was entirely different 15 years ago. But sticking to it, developing an understanding of what good code looks like, eventually lead me to a successful career.
Everyone has their own pace. Be patient with yourself, and learn to love learning. You'll never stop learning in this industry.

I've worked in programming for the last ten years and the most important skill you might not have guessed: Bravery. People are going to say "if it works, don't fix it", but a lot of real-world code barely works, and you need to be willing to break it to make it better.
If you're good at your job, you will spend a lot of time reading other people's code and testing small changes to see what happens. Write "new" code for yourself, because it's fun and its good practice, but also learn to read and repair "old" code.
- I mostly agree with your post. I take exception to the barely works part. Either the code works or it doesn't. If it doesn't work, fix it. If it works, don't fix it.
  If you "fix" working code, you are spending time adding no value to the project. You could even argue you're adding negative value because the people who are used to the code working the way it was now have a surprise.
  
  Good callout! I agree, don't rewrite just for the sake of rewriting. By "barely works" I am referring to code that functions but where a small change to the requirements would make it incorrect. In that situation you should "break it" in order to add changes, rather than calcifying the legacy code by building around it.

Might want to try !programming@programming.dev.

You want code that works as intended instead of through trial and error? TDD (Test-Driven Development).
You don't have to follow a specific process, but you do need to internalize that way of thinking about development, so you can use it as a tool. Tests are a good way (but not the only way) to set your intent, focus your writing, and acknowledge your progress.
If you find tests useful, you might also proceed to mutation testing (jester / pester / mu check) or property testing (quickcheck / hypothesis / fastcheck). Or, even graduate to the real TDD (Type-Driven Development) which is best covered by the "TDD with Idris" book.

Work on your own projects you come up with. Don’t follow videos. Learning along the way works.

Like any skill, practice, and practice often. It's usually better if you jump in with a purpose, with a project in mind. It'll help organize your thoughts and channel your effort, versus just copypastaing an example from the web. Start small, then start combining small things into big things. Gather your tools and eventually you'll have a tool for most things.

Start with a fun hobby website. My first one was Pokemon. Here's all 150 of them, with pictures. Then add dynamic content. Then separate out the database layer.
If it's something fun and personal, you will want to do it. That's how you get the hours in
- k
  
  Foolish. You've violated my instance's sidebar rules and I'll have to ban you. Good luck with basic human decency. 👋

Practice. Their is no shortcut to hard work.

Start with one thing. I presume you have the same issue as me, when it comes to learning new things, too big of a scope. Narrow it down, things take time.

You are trying to learn a lot of different things at once. I don't think you'll find many "coding" experts in the real world, but you will find react experts and flask experts. I think you need to focus on something to get the satisfaction you're craving. You still might not have found your favorite language/framework/project, so it's fine to keep searching as well, but I would avoid going around in a circle spending a week barely scratching the surface of the same 5 skills in a cycle.
You will never stop learning. You will get better, but there will always be something new to learn. Even if 90% of your code works "intentionally" as you say, there will still be 10% that you need to trial and error and stack overflow.

What honestly made a big difference for me was 2 things:
Working IRL for a while so I could see how projects can quickly turn into a mess as new requirements get added on
Learning the SOLID principles and TDD.
The solid principles are a great guide as a project gets large, but you can't really appreciate them until you've worked on a project that is a mess.
So this isn't exactly practical advice for you, but it's what helped me.

Like with anything else, getting good involves practice, practice, practice. You'll encounter problems and you'll learn to solve them as long as you keep up the curiosity and willingness to learn. If you keep asking the question "is there a better way of doing this?" you can keep improving.

37 comments