Keep practicing.
Read other people's code, for example open source project. Contributing to open source can be good practice also.
Find a mentor.
Pick a team at work that has the skills and culture+capacity to mentor you.
this post was submitted on 03 Jul 2023
22 points (95.8% liked)
Ask Experienced Devs
1064 readers
1 users here now
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
Open source contribution can be really great. I started contributing to a Python project that I have used extensively and it 100% improved my coding. It also can allow for you to interact with more experienced devs (depending on the project) and allows for you to get feedback.
BUILD SOMETHING.
Learning concepts without the ability to apply them are essentially useless.
Get your hands dirty and build something that would be valuable to you and solve a problem for yourself.
Don't get hung up on doing it "right". Focus on making it work. Don't worry about how it'll work for a million users. Right now your focus is on making it work for one user.
As you go you'll hit walls. Research how to get past them and keep going. Again, you're going to make mistakes. DO NOT GET HUNG UP ON THIS.
Making mistakes is part of the journey. Even the best software engineers in the world rarely get things right their first try. It's part of the process.
I think this is the best answer. You can follow tutorials and read others' code all you want, but until you have a real-world application of what you're learning, the information you're consuming might as well be lost to the cosmos.
If you want structure, there are plenty of courses on YouTube that can start you out with fundamental knowledge; but as you continue to learn, taking on your own projects increasingly becomes the most efficient way to develop as a developer.
And, of course, there is a place for reading other people's code. I just think that this "method" is popularly miscredited as the way to learn coding, rather than as a tool to fortify your skills.
Don't teach yourself complex software dev skills. Teach yourself complex software problems and learn how others have solved them in the past.
First focus on working on projects instead of improving your skills. The concepts you learn are usually a solution to some problem. Things are easier if you first encounter the problem yourself and then learn the solution, than if you do it in reverse. It is ok to do things poorly when you are starting out.
Like others have said, practice is key, however I'd like to add that you should not feel too discouraged if it feels like you're making no progress. You're probably making more headroom than you realize. At least personally in programming more than anything else I have occasionally only seen results after I came back to a concept I gave up on learning.
Do be aware of getting stuck in local minimum though. I know it probably feels like bad advice but I figured I'd give it since it helped me personally, so maybe it might help someone else.spoiler
When you're at that point, it's usually a sign that you need to start applying what you learned. There are two parts of programming:
- The concepts, the theory which is honestly the fun part.
- Dealing with the little annoyances, setting up a development environment, learning APIs, wiring things together, running into problems there is no clean solution for and implementing something that works.
The second part feels unimportant, something you can always learn later, but it takes time to learn and get good at, and what you need to learn to start to effectively apply more advanced concepts. Otherwise you're learning things you won't be able to use.
Practice practice practice, always challenge and improve on your foundational skills. Everything else gets easier. Write code and solve problems, struggle through it in whatever way works for you. There's not really a shortcut to getting more experience than to put in the work.
It's especially important to try and do things the "right way" as a learning/growth tool. It will take longer, and you'll rewrite your code multiple times, but the next time you encounter a similar problem you suddenly know exactly what to do and the constraints around the problem.
Do this often enough and you'll find yourself having a general idea of how to solve just about any problem you come across, and how to do it elegantly.
No matter what you learn, keep the foundation strong. Religiously follow the "First Principle". For example, instead of learning tons and tons of web framework, try to learn the fundamentals of the language first and how networking works.
Try to understand the concept by yourself. Verify the inert knowledge. Don't rush for the quantity. Take your time and build a strong root. Make time your friend.
You need to practice what you have learnt. Even if it is a hobby project, make it as clean and elegant as possible to learn the implementation of the techniques. Practice makes perfect. And take notes. Organized, detailed notes. Use something like trilium, nextcloud or Google docs.
One thing i undervalued for most of my career was just reading code.
Get into the habit of digging into open source repos that catch your curiousity, and try to grok the way the project is layed out, what namespaces/files exist, what some of the core functions are, where the complexity is housed.
It’s all about getting exposure to patterns, especially if there aren’t other people to work with in your day to day.
Lots of good advice already in this thread, but I'll add: Try interesting professional practices in your personal projects. Try to build your code test driven development, write a contributing guide, keep a changelog, set up automated testing, set up static code analysis, generate a coverage report.
These habits certainly aren't needed for your hobby coding, but they can teach you things about how your coding style compares to others (and be sure to add any you've done to your resume, of course!)
By not learning. Software should be simple not complex.
Software has to model the real world, and the real world is complex. Not to mention that software is not a perfect abstraction, you will have to solve hard problems such as scaling.
Software complexity is unavoidable, how you reduce and control the impacts of that complexity is how you build maintainable software.
Are you sure you should be answering questions here?🤔
This is a great argument. There will always be a healthy friction between the need to model reality in software form and the option of keeping software lean and adapt reality to better fit the solution. Both require really good human-to-human communication skills and sharp comprehension of the real problem.
Good up front understanding of your problem space goes a long way. You don't need to waterfall it, but you should at the minimum have a high level view of the problem and your proposed solution(s). With considerations of where the team/domain might go wrong, where we expect to find pain points, and what sort of mitigations should be considered for those.
Your planning will not survive reality, and that's okay. You are already further ahead as a result of some high level consideration than you might otherwise be, and hopefully you have built your software under the assumption that you will be learning and changing as you go.
Human to human interaction is a baseline necessity for any large work for any field TBF. It's also hard failing point full of nuance, and doesn't really have a panacea as humans are the more complex parts of any system.
Software is hard, not treating it as such means devs will build complex systems because they focused too much on "simplicity". Missing the forest for the trees.
Welcome to suckless.org
Yes, some things need optimization but most don't. Today, there is unnecessary complication by having a billion dependencies and using autocode generators which generate 10k lines of code from 100 lines.
You are conflating necessary complexity vs unnecessary complexity. And assuming that all things are the later, without acknowledging that yes there are many applications that must scale, and that most non-trivial applications must deal with real world complexity. Nevermind scaling being a simple example of a complex problem, not a statement about it's necessity...
I would expect devs here to be experienced enough to understand and differentiate those two, as such assuming the worst isn't a good fit and prevents fruitful discussion.
I would suggest you reconsider the premise you are using here, you appear to be here to complain, not to share and learn.
Give me an example of some software. Implementations of models for weather prediction, CAD softwares, games is difficult, but most software is simple. Even the above softwares don't require the kind of today is served. What do you do in software?
In simple language, code is implementation of some logic into a set of sequential binary. It doesn't have to be complex at all! On the contrary, it's meant to be simple. If it isn't simple, your algorithm is logically unsound.
I agree with your motion of creating simple software, but removing learning complex approaches and complex software don't help with this.
Creating simple software requires understanding of what is complex and how to make it simple. There is no way that you can do this without learning. You either learn this by craft or learn through the practise.
view more: next ›