Programmer and developer are often used interchangeably, but there is an important distinction between them: the developer’s broader perspective an...
For further actions, you may consider blocking this person and/or reporting abuse
Really good article. I'm agree in all of the topics related here except in the "DRY (Don't Repeat Yourself)".
Sometimes you need to RY depending on the context. The best example of such context is in the development of microservices. They should be isolated pieces of code able to finish a single task and do it in the most efficient way. They shouldn't have external dependencies for that and this is the reason because you maybe need to repeat yourself developing microservices. It's true that you can build small dependecies between microservices but if you start with it without a good reason, you will finish with a mess of dependent services for sure. So maybe it's better to repeat yourself than starting a thing that sooner than later you won't be able to control.
And there are more examples not limited to microservices but to commonly development:
testfirst.io/dont-repeat-yourself-...
That is very true actually, DRY is definitely not a general thing like the others. There are always reasons to write either DRY or WET code.
Like with microservices, they are actually DRY as well. You write a small service which can be re-used for anyone who needs it, as opposed to adding that functionality to every project you need it in.
Microservices are more important in companies with many teams working together, to share functionality between the projects without having to duplicate the code. There are always consumers of those microservices which otherwise would have to repeat that code.
Although it's true that DRY is used in Microservices too, it is considered an Anti-Pattern and needs to be avoided, in a single project as much as possible and between projects at any case.
Microservices have to be independently deployable and introducing dependencies to shared libraries or other microservices breaks this principle.
So, to write a "small service which can be re-used for anyone who needs it", seems to me not to be a good idea. I think it should be replied in each project, because you don't know how much it's going to change and you will never know how many other microservices in other projects are using this service and how much a small change can impact them.
Maybe you need someday to change the behavior of this shared microservice for your project and then you need to ask the teams responsible for a change and that team needs to talk with another teams in the same project that use this microservice to inform them about the changes. And maybe this change impacts another projects than need to be updated too and then another teams needs to be addressed and so on. And now imagine this situation happening more times in several teams.
In the best case you will have, for each case, another "similar" microservice to satisfy the need of each team. At the end, the maintainability of so many microservices will become a nightmare.
In the worst case, you will have a microservice doing a lot of similar (or different) things breaking the "S" from SOLID and the maintainability will be anyway a huge problem.
Probably you think I'm overstating, but from my experience I can say that such situations happen more oft than we think.
Also, while the DRY principle remains a fundamental tenet of software engineering, its application in microservices architecture demands careful consideration of the unique challenges and trade-offs involved.
To avoid this kind of dependencies, we can embrace another approaches like Redefine the Boundary by encapsulating the code of the shared library or the Sidecar Pattern among others.
In response to the author's comments about the DRY principle, the critic provides a well-founded counterpoint regarding the context of microservices. While the author acknowledges that DRY can apply to microservices, they overlook the risks of dependency and inter-team coordination that come with applying the principle without caution. The critic rightly emphasizes that in microservices architecture, dependencies on shared libraries or other microservices introduce complexity and compromise the independence of each service.
The core issue is that microservices are intended to be independently deployable, and sharing code or functionality between services can lead to a web of dependencies. This creates a situation where small changes in one service could require updates across many others, leading to unnecessary coordination between teams and potentially introducing unforeseen maintainability challenges. In the worst case, this can cause services to become tightly coupled, ultimately breaking the SOLID principles, particularly Single Responsibility and Maintainability.
As the critic explains, this risk can be avoided by redefining boundaries, such as encapsulating shared functionality or adopting patterns like the sidecar pattern. These approaches allow for reusability without violating the core principles of microservices. The critic’s response highlights the need for a more nuanced application of the DRY principle, especially in the context of microservices, where independence and scalability must be prioritized over code duplication.
Well said
Wow, this is great
It's really Very nice project. I like it.
Great stuff
Very good article !
nice one
This is a real gem of an article. I love your table that lays out what’s the difference between and programmer and a developer.
Great stuff.
Dennis Persson's article, "From Programmer to Software Developer – The Skills That Make the Difference," emphasizes the critical shift in mindset and skill set required to evolve from a task-oriented programmer to a versatile software developer. This transformation involves acquiring not only technical proficiency but also soft skills, such as communication, collaboration, and an understanding of the broader context of the software's impact.
Persson outlines the necessity for programmers to engage in continuous learning and adopt a user-centric approach to development. A successful developer does more than write code—they understand project goals, collaborate effectively within teams, and adapt to changing requirements while considering factors like usability and maintainability.
However, while Persson stresses the importance of this evolution, the broader implications for industry demands and individual growth could be explored further. For instance:
Adaptation to Emerging Technologies: Beyond user needs, software developers must anticipate and adapt to trends like AI integration, cloud-native design, and cybersecurity measures. How does a programmer stay relevant when the industry demands are continually shifting?
Balancing Specialization and Generalization: Persson highlights versatility, but as development becomes increasingly specialized, where is the balance between becoming a "jack of all trades" and excelling in a niche?
Ethical and Environmental Considerations: Software now has global reach and environmental impact. Developers must consider these aspects as integral to their role, shaping not just products but also the societal framework they influence.
The article provides a foundational guide but could benefit from addressing these dynamic aspects that increasingly define the software development landscape.
From the given analysis, the article "From Programmer to Software Developer – The Skills That Make the Difference" does exhibit elements that lean toward promoting the author's authority rather than focusing purely on providing actionable, educational content. Here are the points supporting this view:
Tone and Structure: The tone of the article appears authoritative, with language that implies a definitive understanding of what constitutes success in transitioning from programmer to developer. This could be interpreted as positioning the author as an expert without sufficiently backing claims with evidence or clear examples that readers can apply.
Generalized Advice: The advice offered, while valid in a broad sense, lacks depth in terms of actionable steps or concrete methodologies. For example, stating the importance of "soft skills" or "thinking like a software developer" is not inherently actionable unless accompanied by specific scenarios or strategies to develop these traits.
Potential Bias: The article occasionally employs persuasive language that could be construed as self-promotional. This might detract from its educational value, as it focuses on establishing credibility rather than providing new insights or fostering deeper understanding.
Unaddressed Critiques: There is a missed opportunity to critically analyze challenges or misconceptions about the programmer-to-developer transition. By glossing over potential difficulties or nuances, the content leans more toward a prescriptive narrative than an exploratory or balanced one.
Recommendations for Improvement
Incorporate detailed examples or case studies to illustrate the points discussed, making the advice more actionable for readers.
Address challenges and counterpoints to the transition, offering a more nuanced perspective.
Reduce self-promotional elements and focus on fostering a dialogue or offering resources that enhance learning.
While the article provides a solid starting point, these adjustments would improve its balance between establishing the author’s credibility and delivering genuinely educational value.
I always considered the difference to be based upon when you were born
if i may ask, what's the difference between software developer and and software engineer?