Kutipan Inspiratif untuk Pengembang Software bagian-6
Di blog ini, kami mengumpulkan kata-kata inspiratif dalam bahasa Inggris yang kami anggap bijaksana dan masih dapat diterapkan. Kutipan kata-kata ini dari orang-orang yang terkenal dan diterima di berbagai bidang industri software.
Pada bagian-6 ini akan diambil dari: Larry Bernstein, Larry Bossidy, Larry Constantine, Larry Flon, Larry Wall, Larry Tesler, Laurence J. Peter, Linus Torvalds, Lisa Crispin, Louis Srygley, Marc Donner, Mario Fusco, Mark Berry, Mark Fewster, Martin Fowler, Mary Poppendieck, Max Kanat-Alexander, Melinda Varian, Mich Ravera, Michael Feathers, Michael Hartung, Michael A. Jackson, Michael Lopp, Michael Nygard, Mike Cohn, Mike Krieger, Mikko Hypponen, Milt Bryce, Neal Ford, Nicole Forsgren, Nicoll Hunt, Niklaus Wirth, Nitin Borwankar, Norm Schryer, Norman Ralph Augustine, Oscar Godson.
Untuk bagian-1 bisa dibaca di sini
Untuk bagian-2 bisa dibaca di sini
Untuk bagian-3 bisa dibaca di sini
Untuk bagian-4 bisa dibaca di sini
Untuk bagian-5 bisa dibaca di sini
Larry Bernstein (A software engineering professor, teaching software architecture at NJCSE, led major software projects at Bell Labs for 35 years)
“Don’t automate an undisciplined workflow. The computer won’t solve what the customer’s management can’t.”
Larry Bossidy (An American writer and retired businessman served as CEO of AlliedSignal -later Honeywell in the 1990s. He previously served in executive positions at General Electric for over 30 years.)
“Complexity has nothing to do with intelligence, simplicity does.”
“The foundation of changing behavior is linking rewards to performance and making the linkages transparent.”
“The hardware of a computer is useless without the right software. Similarly, in an organization the hardware (strategy and structure) is inert without the software (beliefs and behaviors).”
Larry Constantine (A software engineer and professor at the Department of Mathematics and Engineering at Madeira University, has many publications on software science and corporate culture, considered as one of the pioneers of structural software design methodologies and specializes in interaction design and usability in complex systems)
“The best meetings get real work done. When your people learn that your meetings actually accomplish something, they will stop making excuses to be elsewhere.”
Larry Flon (An American computer science professor)
“There is no programming language, no matter how structured, that will prevent programmers from making bad programs.”
Larry Wall (The creator of the Perl programming language)
“The three chief virtues of a programmer are: Laziness, Impatience and Hubris. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hubris: The quality that makes you write (and maintain) programs that other people won’t want to say bad things about.”
“Computer languages differ not so much in what they make possible, but in what they make easy.”
Larry Tesler (A computer scientist who worked at Apple between 1980 and 1997, recognized as the inventor of the “Cut-Copy-Paste” commands on computers.)
“Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it, the user or the developer (programmer or engineer).”
Laurence J. Peter (A Canadian educator and writer, best known for his “Peter principle” on hierarchy, published “Peter’s Almanac” in 1982)
“Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.”
Linus Torvalds (A software engineer and the creator of the Linux kernel)
“Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.”
“Theory and practice sometimes clash. And when that happens, theory loses. Every single time.”
“Telling people “don’t do that” simply doesn’t work. Not if they can do it easily anyway. Things really don’t get fixed unless people have a certain pain-level to induce it to get fixed.”
Lisa Crispin (Specialized in agile methodologies and testing, has four books, helps testing community learn about DevOps and continuous delivery, and helps agile and DevOps communities know about testing, explores best practices in testing in the software community.)
“People, not methodologies or tools, make projects successful.”
Louis Srygley (Has 30+ years of software career, is also a producer and an actor)
“Without requirements or design, programming is the art of adding bugs to an empty text file.”
Marc Donner (An American computer scientist with a Ph.D. in robotics, worked at companies such as IBM Watson Research Center, Google, and Uber)
“Of all my programming bugs, 80% are syntax errors. Of the remaining 20%, 80% are trivial logical errors. Of the remaining 4%, 80% are pointer errors. And the remaining 0.8% are hard.”
Mario Fusco (An Italian software engineer and Java expert, the author of the book “Java 8 in Action: Lambdas, Streams, and Functional-style Programming”, co-author of the book “Modern Java in Action”, currently works as “Drools Core Developer” in Red Hat)
“The code you write makes you a programmer. The code you delete makes you a good one. The code you don’t have to write makes you a great one.”
“Sometimes a bug is so big & you’re so focused on details that discovering it is like finding an elephant with a microscope. Take a step back.”
“Programs, like people, get old. We can’t prevent ageing, but we can understand its causes, limit its effects and reverse some of the damage.”
“You can optimise for low latency. You can optimise for high throughput. You can optimise for memory occupation. However 90% of times the most precious thing you should optimise for is maintainability.”
Mark Berry (A software engineer and entrepreneurs)
“Programmers don’t burn out on hard work, they burn out on change-with-the-wind directives and not ‘shipping’”
Mark Fewster (A consultant in the field of test techniques and test automation, lecturer, author, speaker, co-author of the book “Software Test Automation”, has more than 20 years of industry experience in the field of software testing)
“It is far better to improve the effectiveness of testing first than to improve the efficiency of poor testing. Automating chaos just gives faster chaos.”
Martin Fowler (An English software developer specialized in agile software development methodologies including object-oriented analysis and design, UML, patterns and over-programming, a writer and an international speaker on software development, the author of many books including “Refactoring”)
“If you’re afraid to change something it is clearly poorly designed.”
“Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.”
“A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.”
“If you can get today’s work done today, but you do it in such a way that you can’t possibly get tomorrow’s work done tomorrow, then you lose.”
“I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.”
“When you find you have to add a feature to a program, and the program’s code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.”
Mary Poppendieck (Started her career as a process control programmer, led the IT department of a manufacturing facility, and then shifted to product development, wrote four books on “Lean Software Development”, including “Implementing Lean Software Development: From Concept to Cash”)
“Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won’t be needed.”
“The biggest cause of failure in software-intensive systems is not technical failure; it’s building the wrong thing.” “Almost everything we know about good software architecture has to do with making software easy to change.”
“It is much more important to develop people with the expertise to make wise decisions than it is to develop decision-making processes that purportedly think for people.”
“It would be much better to assign work to established teams than to reconstitute teams around projects.”
“A disciplined approach to problem solving moves a team from wishful thinking to new knowledge, specific countermeasures, and permanent results.”
“The job of tests, and the people that develop and runs tests, is to prevent defects, not to find them.”
“If the vision of perceived integrity isn’t refreshed regularly, the engineers have a tendency to get lost in the technical details and forget the customer values.”
Max Kanat-Alexander (Software developer at Google and author of ‘Code Simplicity’)
“Some of the best programming is done on paper, really. Putting it into the computer is just a minor detail.”
“Simplifying your code decreases the effort of maintenance, thereby increasing the desirability of every other possible change.”
Melinda Varian (A programmer and an academician at Princeton University has studies and articles on the history of IBM’s virtual machine operating system VM)
“The best programs are the ones written when the programmer is supposed to be working on something else.”
Mich Ravera (A software developer and publisher)
“If it doesn’t work, it doesn’t matter how fast it doesn’t work.”
Michael Feathers (Specialized in software and organizational design, has provided consultancy support to hundreds of organizations in the past 20 years on general software design, process change and code animation, is the author of “Working Effectively With Legacy Code”)
“Remember, code is your house, and you have to live in it.”
“The brutal truth is that architecture is too important to be left exclusively to a few people. It’s fine to have an architect, but the key way to keep an architecture intact is to make sure that everyone on the team knows what it is and has a stake in it.”
“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
“Clean code always looks like it was written by someone who cares.”
“In a well-maintained system, it might take a while to figure out how to make a change, but once you do, the change is usually easy and you feel much more comfortable with the system. In a legacy system, it can take a long time to figure out what to do, and the change is difficult also.”
Michael Hartung (A computer hardware specialist who has worked at IBM for many years, was appointed an IBM Fellow in 2002)
“Hardware eventually fails. Software eventually works.”
Michael A. Jackson (A British computer scientist and computing consultant, visiting research professor at Open University in the UK, and author of many books)
“We follow two rules in the matter of optimization: Rule 1: Don’t. Rule 2: (for experts only). Don’t do it yet – that is, not until you have a perfectly clear and unoptimized solution.”
Michael Lopp (An American software engineering executive, blogger, known as “Rands”, and the author of “The Art of Leadership: Small Things, Done Well”, “Managing Humans: Biting and Humorous Tales of a Software Engineering Manager” and “Being Geek: The Software Developer’s Career Handbook”.)
“A software metaphor is more like a searchlight than a road map. It doesn’t tell you where to find the answer; it tells you how to look for it.”
Michael Nygard (An American programmer, architect and author.)
“Design with skepticism, and you will achieve resilience. Ask, “What can system X do to hurt me?” and then design a way to dodge, duck, dip, dive, and dodge whatever wrench your supposed ally throws.”
Mike Cohn (Contributed to the development of Scrum, one of the founders of the Scrum Alliance, has books on agile methodology, supports the daily stand-up meetings)
“The benefit of allowing a team to self-organize isn’t that the team finds some optimal organization for its work that a manager may have missed. Rather, it is that by allowing the team to self-organize, it is encouraged to fully own the problem of performing its work.”
“Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent.”
“Individuals should be given every incentive possible to work as a team. If the team’s throughput is increased by my helping someone else, that’s what I should do.”
Mike Krieger (Brazilian-Amerikan entrepreneur, software engineer and Instagram co-founder.)
“You can’t start a product simply by building it. You have to know why you’re building it, and you might go down the wrong rabbit hole, waste time, and confuse things. Spending long afternoons with a sketchbook or talking through your ideas with other people can save a year in software development later on.”
Mikko Hypponen (Finnish computer security and privacy expert and columnist, known globally for the Hypponen Law on IoT security)
“Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.”
Milt Bryce (An information systems expert)
“No amount of elegant programming or technology will solve a problem if it is improperly specified or understood to begin with.”
Neal Ford (Completed his university education as a computer scientist who specializes in languages and compilers and a mathematician who specializes in statistical analysis. Known as an expert in agile engineering techniques and software architecture. Has many articles, books, and videos on software architecture, continuous distribution, functional programming)
“The problem with a completely new programming paradigm isn’t learning a new language. After all, everyone reading this has learned numerous computer languages—language syntax is merely details. The tricky part is learning to think in a different way.”
Nicole Forsgren (An American technology executive, entrepreneur, and author.)
“Architects should collaborate closely with their users—the engineers who build and operate the systems through which the organization achieves its mission—to help them achieve better outcomes and provide them the tools and technologies that will enable these outcomes.”
“Responsibilities of a team leader include limiting work in process and eliminating roadblocks for the team so they can get their work done.”
Nicoll Hunt (Has 20+ years in the software, mainly worked in game development and developed games such as Fist Of Awesome, Shirtless Bear-Fighter, Maximum Car, 8-Bit Waterslide)
“The first step of any project is to grossly underestimate its complexity and difficulty.”
Niklaus Wirth (A Swiss computer scientist, designed many programming languages including Pascal, and pioneered classical topics in software engineering)
“A primary cause of complexity is that software vendors uncritically. adopt almost any feature that users want.”
Nitin Borwankar (A database specialist with 20 years of industry experience)
“Don’t put your resume ahead of the requirements.”
Norm Schryer (A computer scientist and president at AT&T Broadband Services Research)
“When code and comments disagree, both are probably wrong.”
Norman Ralph Augustine (A businessman who worked in the field of aviation and space and chaired the “Human Space Flight Plans Committee” and published the “Augustine’s Laws” list in 1984)
“Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics; i.e. it always increases.”
Oscar Godson (A software developer and entrepreneur)
“One of the best programming skills you can have is knowing when to walk away for a while.”
Semoga artikel menginspirasi para pembacanya.