Ask Lemmy

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.

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.

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.

1. 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.
2. 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.

Same as anything else, hours of practice

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.

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.

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.

Practice. Write bad code, come back later and rewrite it. Repeat.

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.

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.

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.

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.

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

Practice. Their is no shortcut to hard work.

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

Might want to try !programming@programming.dev.

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.

What honestly made a big difference for me was 2 things:

1. Working IRL for a while so I could see how projects can quickly turn into a mess as new requirements get added on
2. 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.