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.
You must log in or # to comment.
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.
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.
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.
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.
Work on your own projects you come up with. Don’t follow videos. Learning along the way works.
Same as anything else, hours of practice
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.
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.
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.
Practice. Their is no shortcut to hard work.
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.
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. 👋
Hi stinky, im not sure what you are talking about.
Am i going to be okay?
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.
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.
