🤖〽️Prompt Engineering: Copilot Unabridged (Part 76: Accountability in the Age of Machine-Written Code)

Prompt Engineering Series

Prompt: "write a post of 600 words on who should be held accountable for the decisions taken by machines when code is written by machines as well?"

Introduction

As Artificial Intelligence (AI) continues to evolve, we are entering a new frontier - one where machines not only make decisions but also write the code that governs those decisions. This shift raises a profound ethical and legal question: Who should be held accountable when things go wrong?

When a machine writes code that leads to a faulty decision - say, a misdiagnosis in healthcare or a discriminatory hiring algorithm - the traditional chain of responsibility becomes blurred. If no human directly authored the logic, can anyone be held liable?

The Rise of Machine-Generated Code

Machine-generated code is no longer science fiction. Tools like GitHub Copilot, OpenAI Codex, and other generative AI systems can produce functional code based on natural language prompts. These systems are trained on vast repositories of human-written code and can synthesize new logic with remarkable speed and accuracy.

But they are not infallible. They can replicate bugs, embed biases, or misinterpret intent. And unlike human developers, they lack moral judgment, contextual awareness, and accountability.

The Accountability Vacuum

When a machine writes code and another machine executes it, we face a vacuum of responsibility. There’s no single human decision-maker to blame. Instead, accountability must be distributed across several layers:

• Developers: configure and supervise AI coding tools
• Organizations: deploy and monitor machine-generated systems
• Tool Creators: design the AI models that generate code
• Regulators: define standards and enforce compliance
• Users: provide input and feedback on system behavior

This layered model acknowledges that while machines may write code, humans still shape the environment in which those machines operate.

Developers as Curators, Not Creators

In this new paradigm, developers act more like curators than creators. They guide the AI, review its output, and decide what to deploy. If they fail to properly vet machine-generated code, they bear responsibility - not for writing the code, but for allowing it to run unchecked.

This shifts the focus from authorship to oversight. Accountability lies not in who typed the code, but in who approved it.

Transparency and Traceability

To assign responsibility fairly, we need robust systems for transparency and traceability. Every piece of machine-generated code should be:

• Logged: With metadata about who prompted it, when, and under what conditions.
• Audited: With tools that detect bias, security flaws, and ethical risks.
• Versioned: So changes can be tracked and errors traced to their origin.

These practices create a paper trail that helps identify where human judgment failed - even if the code itself was machine-authored.

Can Machines Be Accountable?

Some argue that as machines become more autonomous, they should bear some form of accountability. But this raises philosophical and legal dilemmas. Machines lack consciousness, intent, and moral agency. They cannot be punished, rehabilitated, or held liable in any meaningful way.

Instead, accountability must remain human-centric. Machines may act, but humans must answer.

A New Ethical Framework

To navigate this complexity, we need a new ethical framework - one that recognizes:

• Intent vs. impact: Even if no harm was intended, impact matters.
• Oversight vs. authorship: Responsibility lies with those who supervise, not just those who create.
• Systemic accountability: Errors often reflect systemic failures, not individual negligence.
• This framework helps us move beyond blame and toward responsible governance.

Conclusion: Humans Behind the Curtain

Even when machines write code, humans remain behind the curtain. They design the systems, set the parameters, and choose what to deploy. Accountability must reflect this reality.

In the age of machine-generated decisions, we don’t need scapegoats - we need stewards. People who understand the power of AI, respect its limitations, and take responsibility for its outcomes.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 75: Developers and the Weight of Machine Decisions)

Prompt Engineering Series

Prompt: "white a post of 600 words on who should be held accountable for the decisions taken by machines"

Introduction

As Artificial Intelligence (AI) systems become more autonomous and influential, the question of accountability looms large. When an AI system makes an erroneous decision - whether it denies a loan unfairly, misdiagnoses a patient, or causes a self-driving car accident - how much responsibility falls on the developers who built it?

This isn’t just a technical issue. It’s a moral and legal challenge that forces us to rethink the boundaries of human agency in a world increasingly shaped by machine logic.

Developers: Architects of Intelligence

Developers are the architects of AI systems. They design the algorithms, select training data, define objectives, and implement safeguards. Their choices shape how machines “think,” what they prioritize, and how they respond to uncertainty.

When an AI system makes a mistake, it often reflects a flaw in one of these foundational layers. For example:

• Biased training data can lead to discriminatory outcomes.
• Poor model design may cause misclassification or faulty predictions.
• Lack of explainability can make it impossible to trace errors.

In these cases, developers bear significant responsibility - not because they intended harm, but because their decisions directly influenced the machine’s behavior.

The Limits of Developer Responsibility

However, it’s important to recognize that developers operate within constraints. They rarely act alone. AI systems are built in teams, deployed by organizations, and governed by business goals. Developers may not control:

• The final application of the system
• The data provided by third parties
• The operational environment where the AI is used

Moreover, many errors arise from emergent behavior - unexpected outcomes that weren’t foreseeable during development. In such cases, blaming developers exclusively may be unfair and counterproductive.

Shared Accountability

A more nuanced view is that responsibility should be shared across the AI lifecycle:

• Stakeholder: Role in Accountability
• Developers: Design, implementation, testing
• Data Scientists: Data selection, preprocessing, model tuning
• Organizations: Deployment, oversight, risk management
• Regulators: Standards, compliance, legal frameworks
• Users: Proper use, feedback, escalation

This shared model recognizes that AI decisions are the product of a complex ecosystem - not a single coder’s keystroke.

Transparency and Traceability

One way to clarify developer responsibility is through algorithmic transparency. If developers document their design choices, testing procedures, and known limitations, it becomes easier to trace errors and assign responsibility fairly.

This also supports ethical auditing - a process where independent reviewers assess whether an AI system meets safety, fairness, and accountability standards. Developers who embrace transparency are less likely to be scapegoated and more likely to contribute to responsible innovation.

Ethical Design as a Developer Duty

While developers may not be solely responsible for every machine decision, they do have a duty to embed ethical principles into their work. This includes:

• Bias mitigation: Actively testing for and reducing discriminatory patterns.
• Explainability: Ensuring models can be understood and interrogated.
• Robustness: Designing systems that handle edge cases and uncertainty.
• Fail-safes: Building mechanisms to detect and respond to errors.

These practices don’t eliminate risk, but they demonstrate a commitment to responsible development - and that matters when accountability is on the line.

Conclusion: Responsibility Without Blame

Developers are not omnipotent, but they are not innocent bystanders either. They occupy a critical position in the AI value chain, and their decisions have real-world consequences. Holding them accountable doesn’t mean blaming them for every failure - it means recognizing their influence and expecting ethical rigor.

In the age of intelligent machines, responsibility must evolve. It’s not about finding someone to blame - it’s about building systems, teams, and cultures that prioritize safety, fairness, and transparency from the ground up.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 74: Accountability in the Age of Intelligent Machines)

Prompt Engineering Series

Prompt: "write a post of 600 words on who should be held accountable for the decisions taken by machines"

Introduction

As Artificial Intelligence (AI) systems increasingly make decisions that affect human lives - from approving loans to diagnosing illnesses and driving cars - the question of accountability becomes urgent and complex. Who should be held responsible when a machine makes a mistake, causes harm, or acts in a way that defies ethical norms?

This isn’t just a legal or technical issue - it’s a moral one. Machines don’t possess intent, conscience, or moral agency. Yet their decisions can have real-world consequences. So who bears the burden of accountability?

The Human Chain of Responsibility

At the core of any machine decision lies a chain of human involvement. This includes:

• Developers: They design the algorithms, train the models, and define the parameters. If a machine behaves in a biased or harmful way due to flawed design, developers may bear partial responsibility.
• Organizations: Companies that deploy AI systems are responsible for how those systems are used. They choose the context, set the goals, and determine the level of oversight. If a bank uses an AI model that discriminates against certain applicants, the institution - not the machine - is accountable.
• Regulators: Governments and oversight bodies play a role in setting standards and enforcing compliance. If regulations are vague or outdated, accountability may be diffused or unclear.

Users: In some cases, end-users may misuse or misunderstand AI systems. For example, relying blindly on a chatbot for medical advice without verifying its accuracy could shift some responsibility to the user.

Can Machines Be Accountable?

Legally and philosophically, machines cannot be held accountable in the same way humans are. They lack consciousness, intent, and the capacity to understand consequences. However, some argue for a form of 'functional accountability' - where machines are treated as agents within a system, and their actions are traceable and auditable.

This leads to the concept of algorithmic transparency. If a machine’s decision-making process is documented and explainable, it becomes easier to assign responsibility. But many AI systems operate as 'black boxes', making it difficult to pinpoint where things went wrong.

The Problem of Diffused Blame

One of the biggest challenges is the diffusion of blame. In complex AI systems, responsibility is often spread across multiple actors. This can lead to a scenario where no one feels fully accountable - a phenomenon known as the 'responsibility gap'.

For example, if a self-driving car causes an accident, who is to blame? The manufacturer? The software developer? The owner? The data provider? Without clear frameworks, accountability becomes a game of finger-pointing.

Toward Ethical Accountability

To navigate this landscape, we need new models of accountability that reflect the realities of machine decision-making:

• Shared Responsibility: Recognize that accountability may be distributed across stakeholders. This requires collaboration and clear documentation at every stage of development and deployment.
• Ethical Design: Embed ethical principles into AI systems from the start. This includes fairness, transparency, and safety. Developers should anticipate potential harms and build safeguards.
• Legal Frameworks: Governments must update laws to reflect the role of AI in decision-making. This includes liability rules, consumer protections, and standards for algorithmic auditing.
• Human Oversight: Machines should not operate in isolation. Human-in-the-loop systems ensure that critical decisions are reviewed and validated by people.

Final Thought: Accountability Is Human

Ultimately, accountability for machine decisions must remain a human responsibility. Machines are tools - powerful, complex, and sometimes opaque - but they are not moral agents. As we entrust them with more authority, we must also take greater care in how we design, deploy, and monitor their actions.

The future of AI is not just about smarter machines - it’s about wiser humans. And that begins with owning the consequences of the technologies we create.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 51: Will AI Make Programmers Obsolete?)

Prompt Engineering Series

Prompt: "write a blogpost of 600 words on how AI may start making programmers obsolete"

Introduction

Artificial intelligence (AI) is rapidly transforming industries, automating tasks, and reshaping the way we interact with technology. One of the most debated topics in the tech world is whether AI will eventually replace programmers, making human coding skills obsolete. While AI-driven coding tools are becoming more advanced, the future of programming is more nuanced than a simple replacement scenario.

The Rise of AI in Software Development

AI-powered coding assistants, such as GitHub Copilot and OpenAI’s Codex, have demonstrated impressive capabilities in generating code, debugging, and optimizing software development workflows. These tools can analyze vast amounts of programming data, predict code structures, and even suggest solutions to complex problems.

AI-driven automation is particularly useful for repetitive coding tasks, such as writing boilerplate code, fixing syntax errors, and generating test cases. This efficiency allows developers to focus on higher-level problem-solving rather than spending time on routine coding tasks.

How AI is Changing the Role of Programmers

Rather than making programmers obsolete, AI is shifting the nature of programming. Developers are increasingly becoming AI supervisors, guiding AI-generated code, ensuring accuracy, and refining AI-driven solutions. Instead of writing every line of code manually, programmers are leveraging AI to enhance productivity and streamline development processes.

AI is also democratizing coding by enabling non-programmers to create software using natural language prompts. Low-code and no-code platforms powered by AI allow users to build applications without extensive programming knowledge. While this reduces the barrier to entry, it does not eliminate the need for skilled developers who understand system architecture, security, and optimization.

Limitations of AI in Programming

Despite its advancements, AI still faces significant limitations in software development:

• Lack of Creativity and Contextual Understanding: AI can generate code based on patterns, but it struggles with creative problem-solving and understanding the broader context of a project. Human programmers bring intuition, innovation, and domain expertise that AI cannot replicate.
• Error-Prone Code Generation: AI-generated code is not always reliable. It can introduce security vulnerabilities, logical errors, or inefficient solutions that require human oversight. Programmers play a crucial role in reviewing, testing, and refining AI-generated code.
• Ethical and Security Concerns: AI-driven coding tools can inadvertently introduce biases, security risks, and compliance issues. Developers must ensure that AI-generated code aligns with ethical standards and industry regulations.
• Complex Software Development: Large-scale software projects require architectural planning, debugging, and integration across multiple systems. AI can assist in coding, but human expertise is essential for designing robust and scalable solutions.

The Future of Programming in an AI-Driven World

While AI is transforming software development, it is unlikely to make programmers obsolete. Instead, the role of programmers will evolve into a more strategic and supervisory position. Developers will focus on guiding AI, ensuring code quality, and solving complex problems that require human intuition.

AI will continue to enhance productivity, automate repetitive tasks, and democratize coding, but human programmers will remain essential for innovation, security, and ethical decision-making. The future of programming is not about replacement - it’s about collaboration between AI and human intelligence.

Conclusion

AI is revolutionizing software development, but it is not eliminating the need for programmers. Instead, it is reshaping the industry, making coding more efficient and accessible while requiring human oversight for creativity, security, and complex problem-solving. Rather than fearing obsolescence, programmers should embrace AI as a powerful tool that enhances their capabilities and expands the possibilities of software development.

Disclaimer: The whole text was generated by Copilot (under Windows 10) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

#️⃣Software Engineering: Mea Culpa (Part X: A Look Beyond AI)

Software Engineering Series

What’s the point of blogging when AI can do a better job than the average blogger? Frankly, one can generate a huge volume of content that’s comparable with the one of the best bloggers. One just needs a set of well-suited prompts and a bit of formatting, though also the formatting can be handled over prompts. So, what’s the point of blogging anyway? Frankly, the more AI takes over, the less space is available for bloggers! Taking a trendy way of formulating titles: is blogging dead? I really hope not!

I’ve been blogging for almost 20 years. Even if I haven’t managed to blog constantly, given the volume of work and learning, I still made it over time! Often it was late in the night, in between other activities, or a bit of work while watching a football game. With AI life changes more than we want. AI can currently write about 20-30% of the code, at least the initial structure on which it can build upon, and it saves a lot of time!

So, the average programmer needs to adapt to the new reality or die?! Becoming unimportant in the programming equation is equivalent with a slow death we witness in our job. Of course, when used wisely AI can provide higher productivity, at least for the moment, though what will happen when the average programmer is not able to keep the pace? What will happen when we can’t review what AI does for us? Probably, we’ll be able to build a smarter AI which can evaluate the output of less smart AI, though what will be the limit?

Just playing the devil’s advocate, though what happens when the devil outsmarts us? Cases of programmers who lost their jobs because of AI become more frequent in the news. This is probably the new reality we need to be accustomed to. AI can write better code, better stories and probably can make faster discoveries than the average programmer, scientist, or any other professions in whose fields AI can be used.

Of course, we can learn to use AI to our advantage, though how many will be capable of doing that? Many programmers will lose their jobs because of AI. Probably, the ones who are still better problem solvers than AI will remain in the business, though until when?! The ones who change jobs wisely early will probably be more adapted to the new paradigm, though at what price? Who will be able to pay the price?

In the first instance the programmers are the ones who’ll suffer, but the chances are high that AI will take over other jobs as well. The shift in teaching and other jobs could change from knowledge transmission to supervision, from creation or simple stand-byers. Does it make sense? Does it help us to live a decent life? Does it help us in the long term?

Probably, all the jobs that need a human touch will be still needed, though it’s challenging to predict how everything will evolve, in which directions, on what terms. The problem is not necessarily AI alone, but the way it is used and misused. Of course, the future doesn’t necessarily need to look that bleak, though the chances of evolving in this direction are high.

AI develops at a faster pace than the human mind can progress. Probably, we’ll be able to benefit from cognitive boosters, developed probably with the help of AI. To any gain is expected also a loss. In which areas should we expect losing something? Is it worth the price we pay for the sake of progress?

Previous Post <<||>> Next Post

✨Performance Management: Productivity (Just the Quotes)

"The productivity of a work group seems to depend on how the group members see their own goals in relation to the goals of the organization." (Paul Hersey & Kenneth H Blanchard, "Management of Organizational Behavior", 1972)

"When companies see their productivity drop, they should ask how they can improve jobs, and not merely by setting up new productivity targets but also by sharing gains with workers and responding to their needs." (Jerome M Rosow, "Management", 1976)

"The productivity of work is not the responsibility of the worker but of the manager." (Peter F Drucker, "Management in Turbulent Times", 1980)

"Stressing output is the key to improving productivity, while looking to increase activity can result in just the opposite." (Andrew S Grove, "High Output Management", 1983)

"Operating managers should in no way ignore short-term performance imperatives [when implementing productivity improvement programs.] The pressures arise from many sources and must be dealt with. Moreover, unless managers know that the day-to-day job is under control and improvements are being made, they will not have the time, the perspective, the self-confidence, or the good working relationships that are essential for creative, realistic strategic thinking and decision making." (Robert H Schaefer, Harvard Business Review, 1986)

"Opportunities abound for linking productivity to business strategy." (John L Grahn, Harvard Business Review, 1986)

"Productivity is closely tied to morale, and morale is a reflection of how people see themselves. If you can improve your employees' perceptions of themselves, you can improve their morale and thereby boost productivity." (Howard Hurst, Personnel Journal, 1986)

"The way to get higher productivity is to train better managers and have fewer of them." (William Woodside, "Thriving on Chaos", 1987)

"A good part of the problem [poor productivity ...] lies with the current accounting system, which sort of makes overhead disappear - it simply gets added into the cost of a product, like a tax." (Paul Strassmann, Inc. Magazine, 1988)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive." (Steve McConnell, "Software Project Survival Guide", 1997)

"Today’s big companies do very little to enhance the productivity of their professionals. In fact, their vertically oriented organization structures, retrofitted with ad hoc and matrix overlays, nearly always make professional work more complex and inefficient." (Lowell L Bryan & Claudia Joyce, "The 21st century organization", 2005)

"Productivity is the name of the game, and gains in productivity will only come when better understanding and better relationships exist between management and the work force. [...] Managers have traditionally developed the skills in finance, planning, marketing and production techniques. Too often the relationships with their people have been assigned a secondary role. This is too important a subject not to receive first-line attention." (William Hewlett, "The Human Side of Management", [speech])

🌡Performance Management: Alfred Thompson's “Over-Educated, Yet Under-Qualified?” [1] (Answer)

Performance Management Series

In schools the accent is on theory and algorithms, the small projects target the learning of a technology, their complexity and difficulties involved being quite small when compared with real life applications. Taking an application from design to production and later during support phase requires time and the mix of knowledge from different fields, thing quite difficult to do in a school project, while the structural context in an organization, the requirements and work in a team, is again quite different. Going above the basic features of a programming language takes time, it depends on the learning curve of the programming language and the capacity of the learner, on the complexity of the tasks approached and on the knowledge (made) available. 

I can’t say that schools can do much in this direction because it’s quite difficult to cover all the aspects in just 8-20 classes, in which the students are introduced into the concepts and some basic applications. What the schools could do in order to support their students is to provide the required infrastructure (mainly computers), bring the technologies and learning material up to date, direct gradually the focus from theory to applicability, and eventually support users getting some additional experience in organizations. It’s in students’ attribution to make most of the learning experience in schools, though often even if the want, need and infrastructure is there, fighting with the lack of time is quite hard.

One of the tough realities in IT is that it takes time to link the dots, and as you already highlighted, it takes about a year before a college/university graduate to become really productive. Now I have to say that this depends also on the organization’s culture/environment, on how it supports the learning process, how it helps the new comer to become part of the team and become productive. I’m saying that because I’ve seen companies doing minimum in this direction, just expecting the new comer to catch everything on the fly and be productive in a matter of weeks. 

Those working in IT for a longer time know that is not entirely possible, though there are also some exceptions. There are also organizations that train the new comers, introduce them into tasks evolving in complexity based on each person’s skills, provide resources (software tools, books, courses and other type of learning material) and an environment that facilitates learning. Having time allocated for learning new things, participating in activities that allow the distribution of knowledge within a team, having professionals whom you could ask questions or who could mentor you through the learning process, I consider all these as being essential for a modern IT organization.

The theory learned in schools need to be supported by hand-on experience in order to make most of the learning process, IT organizations are maybe the best places to do that, though I’m not sure how much that is possible. There are schools, organizations and governments that support this type of learning, though, unfortunately is not everywhere possible to do that or at least not for everybody. I think it’s in everybody’s interest to make most of the learning process, for schools to have highly skilled graduates, for organizations to have productive employees, a pool of college graduates resources from where they could select potential employees, for students to be skilled, and thus have higher chances of finding a job, while for governments this could lead in theory to a smaller unemployment rate. I find important the constructive involvement of all parties; now, I wonder how many schools, organizations or governments are trying to do something, change something into this direction.

References:
[1] Alfred Thompson (2010) “Over-Educated, Yet Under-Qualified?”

🏗️Software Engineering: Programmers (Just the Quotes)

"Programmers should never be satisfied with languages which permit them to program everything, but to program nothing of interest easily." (Alan Perlis, "The Synthesis of Algorithmic Systems", 1966)

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." (Edsger W Dijkstra, "The Humble Programmer", 1972) 

"The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer." (Edsger W Dijkstra, "The Humble Programmer", 1972)

"The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work." (Michael A Jackson, "Principles of Program Design", 1975)

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. […] Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […] The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be." (Fred Brooks, The Mythical Man-Month: Essays, 1975) 

"There is no programming language, no matter how structured, that will prevent programmers from making bad programs. (Larry Flon, "On research in structured programming". SIGPLAN Not. 10(10), 1975)

"The computer programmer is a creator of universes for which he alone is the lawgiver. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or field of battle and to command such unswervingly dutiful actors or troops." (Joseph Weizenbaum, "Computer Power and Human Reason", 1976)

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring: Improving the Design of Existing Code", 1999)

"Good programmers know what to write. Great ones know what to rewrite." (Eric S Raymond, "The Cathedral and the Bazaar", 1999)

"Computer programming is tremendous fun. Like music, it is a skill that derives from an unknown blend of innate talent and constant practice. Like drawing, it can be shaped to a variety of ends – commercial, artistic, and pure entertainment. Programmers have a well-deserved reputation for working long hours, but are rarely credited with being driven by creative fevers. Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see." (Larry O'Brien & Bruce Eckel, "Thinking in C#", 2003)

"Instead of simply correcting mistakes in code, the purpose of code reviews should be to share knowledge and establish common coding guidelines. Sharing your code with other programmers enables collective code ownership." (Mattias Karlsson [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"Of all the principles of programming, Don’t Repeat Yourself (DRY) is perhaps one of the most fundamental. […] The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code than one who continuously infects the application with unnecessary repetition." (Steve Smith, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"Programmers need to be fluent in the language of the machine, whether real or virtual, and in the abstractions that can be related to that language via development tools. It is important to learn many different abstractions, otherwise some ideas become incredibly hard to express. Good programmers need to be able to stand outside their daily routine, to be aware of other languages that are expressive for other purposes. The time always comes when this pays off." (Klaus Marquardt, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"Programming is something some people do - some of the time. And the hard part - the thinking - is the least visible and least appreciated by the uninitiated. […] The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obviously naïve. But the mental process that leads to this mistake is part of human nature, and programmers are just as prone to making it as everyone else." (Alan Griffiths, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others." (Robert C Martin, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"There is an art, craft, and science to programming that extends far beyond the program. The act of programming marries the discrete world of computers with the fluid world of human affairs. Programmers mediate between the negotiated and uncertain truths of business and the crisp, uncompromising domain of bits and bytes and higher constructed types." (Kevlin Henney, "97 Things Every Programmer Should Know", 2010)

"One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"It is not loyalty or internal motivation that drives us programmers forward. We must write our code when the road to our personal success is absolutely clear for us and writing high quality code obviously helps us move forward on this road. To make this happen, the management has to define the rules of the game, also known as "process", and make sure they are strictly enforced, which is much more difficult than 'being agile'." (Yegor Bugayenko, "Code Ahead", 2018)

"Automated testing is a safety net that protects the program from its programmers." (Yegor Bugayenko, "Code Ahead", 2018)

"Quality is a product of a conflict between programmers and testers." (Yegor Bugayenko, "Code Ahead", 2018)

"Quality must be enforced, otherwise it won't happen. We programmers must be required to write tests, otherwise we won't do it." (Yegor Bugayenko, "Code Ahead", 2018)

"We must not blame programmers for their bugs. They belong to them only until the code is merged to the repository. After that, all bugs are ours!" (Yegor Bugayenko, "Code Ahead", 2018)

"We, newbies and young programmers, don't like chaos because it makes us dependent on experts. We have to beg for information and feel bad." (Yegor Bugayenko, "Code Ahead", 2018)

"The environment that nutures creative programmers kills management and marketing types - and vice versa." (Orson S Card, "How Software Companies Die")

🏗️Software Engineering: Data Structures (Just the Quotes)

"At the present time, choosing a programming language is equivalent to choosing a data structure, and if that data structure does not fit the data you want to manipulate then it is too bad. It would, in a sense, be more logical first to choose a data structure appropriate to the problem and then look around for, or construct with a kit of tools provided, a language suitable for manipulating that data structure." (Maurice V Wilkes, "Computers Then and Now", 1968)

"Choosing a better data structure is often an art, which we cannot teach. Often you must write a preliminary draft of the code before you can determine what changes in the data structure will help simplify control. [...] Choose a data representation that makes the program simple." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Let the data structure the program." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Use recursive procedures for recursively-defined data structures." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"The programmer's primary weapon in the never-ending battle against slow system is to change the intramodular structure. Our first response should be to reorganize the modules' data structures." (Fred Brooks, "The Mythical Man-Month: Essays on Software Engineering", 1975)

"The representation of knowledge in symbolic form is a matter that has pre-occupied the world of documentation since its origin. The problem is now relevant in many situations other than documents and indexes. The structure of records and files in databases: data structures in computer programming; the syntactic and semantic structure of natural language; knowledge representation in artificial intelligence; models of human memory: in all these fields it is necessary to decide how knowledge may be represented so that the representations may be manipulated." (Brian C Vickery, "Concepts of documentation", 1978)

"Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures." (Rob Pike, "Notes on Programming in C" , 1989)

"Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." (Rob Pike, "Notes on Programming in C", 1989)

"If a programmer designs a program, only half the job is done if they have only designed the data structures. They also have to design the procedures for operating on the structures. (Specifically, a programmer designs abstract data types.) Without the appropriate procedures for operating on data structures, a computer would literally get lost in the structures, even supposing it could start executing anything sensible." (Yin L Theng et al," 'Lost in hhyperspace': Psychological problem or bad design?", 1996)

"Often you'll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own object." (Kent Beck, "Refactoring: Improving the Design of Existing Code", 1999)

"Smart data structures and dumb code works a lot better than the other way around." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 2001)

"In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful. […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." (Linus Torvalds, [email] 2006)

"Computation at its root consists of a data structure (for input, output, and perhaps something being stored in between) and some process. One cannot talk about the process without describing the data structure. More importantly, different data structures enable certain computations to be done easily, whereas other data structures support other computations. Thus, the choice of data structure (representation) helps explain why a problem-solver does or does not successfully engage in a given process (cognition/behavior) or perhaps why a process takes as long or as short as it does." (Christian D Schunn et al, "Complex Visual Data Analysis, Uncertainty, and Representation", 2007)

"One of the essential parts of a formal training in programming is a long and demanding study of the large collection of algorithms that have already been discovered and analyzed, together with the Data Structures (carefully tailored, seemingly unnatural ways of organizing data for effective access) that go with them. As with any other engineering profession, it is impossible to do a good job without a thorough knowledge of what has been tried before. If a programmer starts the job fully armed with what is already known, they will have some chance of finding something new. Inventiveness is important: not all problems have been seen before. A programmer who does not already know the standard algorithms and data structures is doomed to nothing more than rediscovering the basics." (Robert Plant & Stephen Murrell, "An Executive’s Guide to Information Technology: Principles, Business Models, and Terminology", 2007)

"A modeling language is usually based on some kind of computational model, such as a state machine, data flow, or data structure. The choice of this model, or a combination of many, depends on the modeling target. Most of us make this choice implicitly without further thinking: some systems call for capturing dynamics and thus we apply for example state machines, whereas other systems may be better specified by focusing on their static structures using feature diagrams or component diagrams. For these reasons a variety of modeling languages are available." (Steven Kelly & Juha-Pekka Tolvanen, "Domain-specific Modeling", 2008)

"Clearly, the search for a dividing line between code and data is fruitless—and not particularly flattering to our egos. Let’s abandon any attempt to find a higher truth here, and settle for a pragmatic definition. If a piece of generated text simply instantiates and provides values for a data structure, it’s data; otherwise, it’s code." (Steven Kelly & Juha-Pekka Tolvanen, "Domain-specific Modeling", 2008)

"Generally, the craft of programming is the factoring of a set of requirements into a a set of functions and data structures." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"If the data structure can’t be explained on a beer coaster, it’s too complex." (Felix von Leitner, "Source Code Optimization", 2009)