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.
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.
Practice. Their is no shortcut to hard work.
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.
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.
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).
Might want to try [email protected].
deleted by creator
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.
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.
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.
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.
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
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.
