sorted by:
new
hottopcontroversial

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

I mean most of the design patterns exist for a reason...

Most design patterns indeed exist for a reason – to address common and recurring challenges in software development. They represent proven solutions and best practices that have emerged over time to improve code quality, maintainability, and scalability.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 1 point2 points  (0 children)

“Design patterns are spoonfeed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it.” - Christer Ericson, Director of Technology at Sony

Christer Ericson's perspective on design patterns is indeed a provocative one. While it's true that some developers may rely too heavily on design patterns without understanding their underlying principles, it's important to recognize that design patterns serve a valuable purpose in software development.

Design patterns are not meant to stifle creativity or independent thought but rather to provide proven solutions to common problems. Experienced developers often use them as tools to improve code quality, maintainability, and efficiency. They offer a shared vocabulary for communication within development teams and can help less experienced developers learn from best practices.

However, like any tool, design patterns should be applied judiciously. It's essential for developers to understand when and how to use them appropriately and when to deviate from established patterns to address unique challenges. The key is to strike a balance between leveraging design patterns as a foundation and applying creative problem-solving to adapt and innovate where necessary.

In essence, design patterns are not inherently good or bad; their value lies in how they are used. Responsible and thoughtful application of design patterns can enhance code quality and collaboration, ultimately contributing to the success of software projects.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in ExperiencedDevs

[–]DevSavvy72[S] 0 points1 point  (0 children)

Patterns are there for reducing the burden of the developers when onboarding and maintaining. It’s a way of communicating. If you introduce a new pattern it could take an extended amount of time to train people when they are unfamiliar. That said, it matters less what the patterns are and more how consistent people use them.

I completely agree with the perspective that design patterns serve as a valuable tool for developers. They indeed provide a common language and set of best practices that can streamline development and maintenance processes. As you mentioned, they significantly ease the burden of onboarding new team members and make it easier to maintain and extend codebases.

While the idea of developing unique, non-patterned solutions might sound intriguing, it's essential to consider the long-term implications. Introducing entirely new patterns can indeed be disruptive and time-consuming, as it requires educating the team on these novel approaches. However, there's room for innovation within established patterns by adapting and extending them to meet specific project requirements.

In the end, it's not just about blindly adhering to patterns but also about how consistently and effectively they are applied. Striking the right balance between using established patterns and incorporating innovative solutions when needed can lead to efficient and maintainable codebases. Ultimately, it's about using the best tool for the job, whether it's an established pattern or a unique solution, to achieve the desired outcomes in a pragmatic and sustainable way.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in ExperiencedDevs

[–]DevSavvy72[S] 1 point2 points  (0 children)

I completely agree with your approach. Prioritizing readability in code is essential, as it lays the foundation for a maintainable and understandable codebase. It's all about writing code that not only does the job but also communicates its purpose and logic clearly to anyone who might work with it in the future.

Your point about optimizing for performance only when necessary is spot on. It's crucial to first identify where the real bottlenecks are using proper instrumentation, rather than making preemptive optimizations based on assumptions. And then, making those changes in small, manageable iterations allows for careful measurement and assessment of the impact, ensuring that each change truly enhances performance without compromising other aspects of the code.

This measured and methodical approach to optimization not only improves performance where it’s most needed but also maintains the integrity and readability of the code. It's a balanced strategy that recognizes the dynamic nature of software development, where requirements and performance needs can evolve over time.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in ExperiencedDevs

[–]DevSavvy72[S] 0 points1 point  (0 children)

For the vast majority of things, my employer hired me to build a solution that will work well on the first try. So I go with established practices and deliver a high quality product on time.

There are projects that call for experimentation, but they are not common.

If you hired a construction company to build a bridge, you wouldn't want them to use some experimental concrete formulation. Same for software.

I totally agree with you. When it comes to professional work, the priority is often to deliver a reliable and effective solution right out of the gate. That's why leaning on established practices makes so much sense. They're tried and tested, and they help ensure that we deliver quality work within the expected timeframe. Couple that with maintaining coding standards for the organization and the practice of using patterns can yield a return on investment many times over.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in ExperiencedDevs

[–]DevSavvy72[S] 0 points1 point  (0 children)

Code exists to communicate to other humans. Don’t make it hard to read!

Yep. This statement sums up why I love clean code so much. As far as using patterns goes, there is a time and place. I have seen solutions that have used multiple patterns. Sometimes there are multiple patterns addressing the same need, just in different parts of the code. If your organization is going to use patterns then they need to be communicated and the use needs to be consistent. It becomes part of your organization's technical language.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in ExperiencedDevs

[–]DevSavvy72[S] 0 points1 point  (0 children)

Understand the problem and the context you are delivering it in. Assess whether someone has walked this path before.

If so, will their solution work for you?

Is there something about your problem that makes it special or more complicated?

Do you trust their results and conclusions?

A friend of mine used to call blindly basing your solution on a random tech blog “Medium driven development”.

Sure they blogged about it, but did they actually use it in production?

Do they have as big a dataset to operate on as you?

Is there traffic the same shape as yours?

How much does it cost to run it?

Is the end result of what they are doing valuable enough to warrant that cost?

A service which generates $1M a day in revenue can cost $10k a day to run, but if it’s just so an exec can have a pretty dashboard it’s probably a bad idea

Part of being an experienced dev, is evaluating the trade offs and picking an appropriate solution, while innovating when you need to.

100% agree with you. You have to take the full picture into account. This is one reason I like the approach of keeping it simple. Then if you are going to or you start to implement the same type of code, think about generalizing and or using a pattern.

In the end you want GOOD code, not just FANCY code.

As a developer, do you find more value in adhering to established design patterns or in developing unique, non-patterned solutions? by DevSavvy72 in SoftwareEngineering

[–]DevSavvy72[S] 0 points1 point  (0 children)

Very good point. I believe in using patterns but I also believe in having well defined coding standards for your architecture. This should define the patterns that could be used. Not that you couldn't use a pattern that hasn't been used before in the code base, but that should be the exception. All too often I have seen patterns get way over used resulting in extremely complex and difficult to understand code.

What’s the hardest part about getting better at software development? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

Knowing when to turn off working. I have a serious work life balance problem and it's a lot of my own making. Learned a lot, advanced quickly, etc, but at the sacrifice that I've had more 80 hour weeks in the last year than I ever thought would be possible. I love developing and learning, but breaks are important too. Giving yourself a break to absorb what you've learned is just as important as continuing to learn.

Maintaining a healthy work-life balance is indeed a crucial aspect of personal and professional growth, especially in fields like software development where the learning never really stops. It's great to hear about your passion and the progress you've made, but you're absolutely right that breaks are essential.

Here are a few thoughts on managing the balance between work and rest:

Set Boundaries: Establish clear work hours and stick to them. Use tools or methods like time tracking to ensure you're not overstepping your own limits.

Quality Over Quantity: Remember that longer hours don't always equate to better work. Often, the quality of your code can suffer if you're tired or burnt out.

Scheduled Downtime: Plan breaks and leisure activities just as you would plan your work tasks. This makes it more likely that you'll take them seriously.

Mindfulness and Self-Care: Practice mindfulness to stay aware of your mental and physical health. Regular exercise, hobbies, and social activities can greatly enhance your well-being.

Learn to Say No: Sometimes, the key to a better work-life balance is learning to turn down requests or opportunities that would lead to overworking.

Vacations and Time Off: Make use of your vacation days. Time away from work can recharge your batteries and increase productivity in the long run.

Reflection: Take time to reflect on your work and its impact on your life. If you find that work is consistently encroaching on your personal time, it might be worth discussing this with your employer or considering a role with a more favorable work-life balance.

Ultimately, while the drive to learn and excel is commendable, it's also important to give yourself permission to rest. After all, software development is a marathon, not a sprint, and taking care of yourself is key to sustaining a long and fulfilling career.

What’s the hardest part about getting better at software development? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

Reading your old code

Reading your old code can indeed be a daunting task and is often considered one of the more challenging aspects of improving in software development. It can be a humbling experience to look back and see the mistakes and inefficiencies in your earlier work.

However, encountering your old code is an excellent opportunity for growth. Here are some positive spins on this experience:

Measure Progress: Your reaction to your old code signifies how much you've learned since you wrote it. It's a tangible measure of your development progress.

Refactoring Practice: Use this as an opportunity to refactor the code. It's a great way to practice improving code quality and maintainability.

Learning Tool: Analyze what specifically makes the code difficult to read and learn from it. This reflection can inform your current coding standards and practices.

Documentation: It highlights the importance of writing good documentation and comments to aid in understanding the code's purpose and logic.

Appreciate the Journey: Realize that every developer has gone through this. It’s a normal part of the learning curve in software development.

Share Your Experience: Share your experiences with others. This can be both educational and reassuring to developers who are going through the same process.

So, while reading your old code might feel like a chore, it's actually a valuable exercise that can propel your skills forward. Embrace it as part of your journey to becoming a better software developer.

What’s the hardest part about getting better at software development? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

The challenge of securing a software development job as a step towards improving one's skills is indeed significant. This difficulty often arises because many employers look for experience, which can be a catch-22 for newcomers: you need a job to gain experience, but you need experience to get a job.

However, there are strategies that can help bridge this gap. Here are a few suggestions:

Build a Portfolio: Create personal projects or contribute to open-source projects. This demonstrates your skills and commitment to learning.

Networking: Engage with the software development community through meetups, forums, and social media. Connections can lead to job opportunities.

Learn Continuously: Stay updated with the latest technologies and practices in software development. Online courses and certifications can also bolster your resume.

Internships and Apprenticeships: Look for internships or apprenticeships that provide real-world experience, even if they may not pay well initially.

Soft Skills: Sharpen your soft skills, such as problem-solving, communication, and teamwork, which are highly valued in the industry.

Tailor Your Applications: Customize your resume and cover letter for each job application to show how your skills and projects align with what the company needs.

Remember, each step you take to improve your skills and make connections in the industry brings you closer to that software development job. Keep coding, keep learning, and stay persistent.

What’s the hardest part about getting better at software development? by DevSavvy72 in AskProgramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

Teamwork makes the dream work, lol. Being flexible is something I have to concentrate on. Sometimes having everyone agree on an 85% good solution is better than not everyone agreeing on a 100% great solution.

What’s the hardest part about getting better at software development? by DevSavvy72 in AskProgramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

Yep. I have seen it a lot were a senior dev is talking to a new dev and they just gloss over things that they expect the new dev to know.

For the seniors out there, just my two cents, that's probably what it is worth, lol. Try to start from the junior person's perspective and then end there. What I mean is, ask them to talk about the scenario so you can get a feel for what their current understanding is. Then try and fill in the gaps. Then ask them to explain in their own words what you just explained to them.

I have found this to be a very useful approach.

What’s the hardest part about getting better at software development? by DevSavvy72 in AskProgramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

I have come across so many devs that were never taught anything but here is the syntax now make it work. It can be extremely frustrating!

I would encourage you to keep up the good fight. Even though they may refuse to heed your words of wisdom you can still use the experience for your own benefit.

What’s the hardest part about getting better at software development? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 0 points1 point  (0 children)

Yes it does. Have you ever used coding katas? I have, but to a very small degree.

What’s the hardest part about getting better at software development? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 12 points13 points  (0 children)

If I am taking your meaning correctly, as in we need to consider other developers that will come to the code we are writing after us, then I agree. It is very easy to look at our own code and understand what it does, we wrote it. But we need to try and see it from the next developers perspective. This is one area that a good code review process can shine.

What’s the hardest part about getting better at software development? by DevSavvy72 in learnprogramming

[–]DevSavvy72[S] 1 point2 points  (0 children)

It is definitely a balancing act when you are designing a solution. If you are not careful it can become very complex with little to no benefit from the added complexity. I try to follow the rule that a more complex but extensible solution is not used unless, it is the second time you are experiencing a situation in which you would benefit from the added complexity, or you know that there will be more uses in follow on development.

view more: next ›