Follow+Starred PublicNo., don’t miss exciting content
Source | OSC Open Source Community
Today I will share an article written by a foreign blogger: Code is run more than read (Letting the code run is more important than the readability of the code).
"Code is better to read than written" This sentence is now a consensus among programmers. It reminds us that when writing code, we cannot just pursue convenience and ignore those who need to read and modify the code in the future. More generally, "code is better read than written" conveys the idea that making code easy to understand by keeping it maintainable, keeping it simple, and writing tests and documentation is a wise investment. It's about taking a holistic view of the software development cycle.
Let me express this point more succinctly:
Maintainer > Author
I think this line of thinking can go beyond writing code and be used as a rule of thumb for problem identification and decision-making.
Code is better to use than read
Code is just a means to an end. Software should have a purpose, it should provide a service to the user. No matter how well-written the code is, how maintainable it is, and how advanced the technology used is, it all means nothing if the software doesn’t achieve its goals and give users a good experience:
Users > Maintainers > Authors
Or, since we no longer need to differentiate between developer roles:
Users > Developers
So rather than guessing or asking users what they want, the best approach is to put your program in front of users early and frequently and incorporate their feedback to improve it.
This is a powerful mindset, and by keeping the user in mind during development, we can go far. This is roughly how I learned the profession and how I understood it for the first half of my career.
Code is better to run than read
When I say "run," I don't just mean executing the program, but operating it in a production environment, including deploying, upgrading, observing, auditing, monitoring, repairing, deprecating, and more. As Dan McKinley says: The long-term costs of keeping a system working reliably will almost always far outweigh any inconveniences you encounter while building it.
We can incorporate this idea into our little model:
User > Operation > Development
It took me some time to fully understand this, because in my experience a lot of the software being built never actually gets used in production, at least not at a significant scale. Most software is built on assumptions that are never tested. But when you run your code in a production environment, simplicity takes on a new dimension. It's no longer just about the code itself, but about reducing the moving parts and understanding their failure modes. It's about delivering the product and making sure it works even when something breaks.
In addition, there are commercial factors
I said that keeping the user in mind during development can help us go further. This applies to the assumption that the software is valuable to users and works well. For developers, this is a convenient abstraction: we deliver good, working software, and the business is responsible for turning it into profit. This often works in the consumer and enterprise software world. But ultimately, this abstraction will prove to be an oversimplification, and we could benefit from incorporating some business perspective into our workflow:
Business > Users > Operations > Development
The most obvious example is budgeting: we don't have unlimited resources to satisfy user needs, so costs and benefits need to be weighed. There are also factors such as marketing, deadlines, stakeholders and investors. Personal interests and politics also play a role. Certain decisions that make sense when considering our software, teams, or users in isolation may no longer be appropriate when considering the organization as a whole. Sometimes we need to focus on things that generate revenue rather than just catering to users. I will return to this question again.
Reverse thinking
We're given a small model that expresses the relative importance of various factors in software development, perhaps helping us see the bigger picture and focus on what's important. Now I want to look at some common software development dysfunctions and see how they fit into this model.
Unmaintainable code
Author > Maintainer
This is where we start. It's smart but lazy code turned into spaghetti and a haunted house, it's premature optimization, it's only Carlos touching that module, etc.
Unusable software
Developer > User
Software made by teams that don't learn from users or put technology first. Over-engineered programs, "modernization" that worsens user experience, web applications that break browser functionality, etc.
Only runs on my machine
Developer > Operations
Software designed without operational issues in mind. This is a microservices ecosystem that is overly complex, has many moving parts, high-level databases designed for small data loads, and is managed by a single small team. This is software architected for scale prematurely. This is software designed by different people than the people who are woken up when it breaks.
right thing
Developer > Business
Think of code as a goal in itself. This is software made by pretentious craftsmen, musicians on the Titanic, and Lisp hackers.
Resume-driven development
Developer > *
There is no risk and developers can do whatever they want.
fictional software
Business > User > Operation > Development
This is software that has been built but is rarely (or never) put into production use. I call it fictional software. Charity Majors calls it living a lie.
Business > User > Operation > Development
Another fictional type of software is those that have no users but are scalable (at scale). This is failing to solve the problem or solving the wrong problem, and probably no one cares about the problem. This is software that comes from taking some hyped technology and applying it to everything until a vague fit for a use case appears.
late capitalism
Business > User > Operation > Development
Software with no business model backed by venture capital or whose business model is to grow to a monopoly and then exploit users.
overall view
If you haven't closed your browser tab yet, let me summarize:
Business > Users
This view may be difficult to accept.
As I mentioned above, when I learned this job, software was solving problems for the end user. This is summed up in the last tip of The Programmer's Guide, which says the goal is to satisfy users, not just deliver code. But since I started working as a programmer, and as software has become ubiquitous, I've found this assumption increasingly difficult to maintain.
There is a lot of software being produced that doesn't care about its users, or manipulates users, or turns them into products. This isn't limited to social media: As a user, I can't even book a room, order food, or click the Windows Start button without a popup trying to grab my attention; when I do a Google search, I get a bunch of spam.
What we think it means to do a good job is at odds with what a significant portion of the industry thinks is profitable, and I think this explains the growing discomfort among many software professionals. While we can't shy away from the economic realities of our field, perhaps we should take a stronger ethical stance and not harm users. Acknowledge that users do not always come before business, but business should not always come first:
User > Operations > Development
Business > Operations > Development
Business ≹ User
Reviews:
The origin of shit mountain
Unreadability is a technical barrier
Lack of boss thinking, readability is not opposed to operation and function implementation
Make products, not projects. Need to be cautious.
If the code can run, don't worry about refactoring and optimization.
Original link: https://olano.dev/2023-11-30-code-is-run-more-than-read
Statement:The material of this article comes from the Internet, and the copyright belongs to the original author. If there is any copyright issue with the work, please contact me to delete it.
------------ END ------------
●Column "Embedded Development"
●Embedded column selected tutorials
Follow the public account and reply "Join the group" Join the technical exchange group according to the rules and reply "1024 " See more.
Click "Read the original text" to view more shares.