Keras is one of the most popular open source deep learning frameworks and has a strong influence in both industry and academia. Keras was invented by Francois Chollet, a Google heavyweight and author of the best-selling Python Deep Learning book. How good is this guy? To give a simple example, there are three data: 3.8K + citation times of a single paper on Google Scholar, 41K + number of STAR on a single project on Github, and 15.8k+ number of likes on a single blog on Medeium.
As a world-renowned ai champion, Francois has another identity: Software Engineer, commonly known as code farmer. Even the most advanced algorithms need to be implemented through Coding and serve users in the form of software products. Therefore, programming ability and software engineering thought, for any algorithm researcher/algorithm engineer/software developer, is not only basic skills, but also need to continue to hone important skills.
What does Francois, a coder, think of programming and software engineering? His recent post on Medium, which received ** 15.8K +** likes, answers that question. Although the title of the article is Notes to Myself on Software Engineering, it is also addressed to all programmers. After my translation, induction and sorting, finally refined out of the dry goods of 20 suggestions, one by one listed as follows.
1. Readability is a fundamental requirement of programming. Because code is not just for execution, code is a way of communicating between team members.
2. Programming needs Taste. What is taste? Taste is the desire for and the ultimate pursuit of Simplicity.
3. Learn to reject demands. Each new requirement will cost more to develop than originally estimated, especially maintenance costs, documentation costs, and user perceptions. Always ask yourself: Should we really be doing this? The answer is usually no.
4. When there is a real need to support new requirements, it is often the right thing to do to extend existing functionality rather than start from scratch.
5. It pays to invest in continuous integration (CI) to ensure that everyone is in a confident (confidence is more important than gold) programming environment.
6. It doesn’t matter if you don’t plan everything out in advance, give it a try and see what happens. Like reverting problematic code, it is a mistake to Revert early.
7. Just because a problem looks difficult doesn’t mean its solution has to be complicated. Before writing any code, make sure your solution doesn’t get any simpler. Do everything from first principles.
8. Apis have users and therefore need to focus on the user experience. Be mindful of your users, whether they are beginners or experienced developers.
9. Always seek to reduce the cognitive burden of using apis: automate what can be automated, minimize the actions and choices required by users, don’t expose unimportant options, and design simple and consistent workflows.
10. API naming and parameter naming should focus on What the API solves, not How.
11. Focus on end-to-end workflows rather than a set of discrete atomic functions. Instead of asking “What features should be provided?” programmers should ask “What is the user story? What is the optimal sequence of actions for each user scenario? How to support this workflow with the simplest API?” .
12. Error messages, as well as any Feedback provided to the user during an interaction, are part of the API and directly affect the user experience. Therefore, carefully design your API’s error message and feedback mechanism.
Documentation is at the heart of the API user experience. Investing in high-quality documentation will pay off more than investing in new features.
14. What is good documentation? Good documentation is reader-centric. It should not discuss how the software works, but how to use the software; It should show an end-to-end workflow with code examples; It should show code examples of common uses of the API and key functions.
15. Career development is not about how many people you can manage, but how many people you can influence.
Software development is a kind of teamwork, which is not only about technical ability, but also about interpersonal relationship. As you move forward, remember to Keep in touch with people.
17. Technology is never neutral. All technical decisions are ethical. When designing software products, we should not only consider technical factors, but also consider the ethical or moral impact of software.
18. Create the software the world needs, not just the software you want. Technologists need to take every opportunity to expand their life experiences and better understand the real needs of the world.
19. The trade-off between the speed of decision making and the quality of decision making varies greatly in different environments. Sometimes good intuition can make the right decision with insufficient information. Sometimes, you need to delay action to wait for more information, because the cost of making a wrong decision is higher than the cost of delaying it.
20. Experience is a big factor in Productivity, and higher Productivity gives you more experience. It’s a virtuous circle.
Francois Chollet’s advice, what do you think? Welcome to express your views, thank you!
My name is Xiao Ge Shelwin, a high quality software engineering practitioner and promoter. Welcome to scan the qr code below, add my personal public account test will not do, get more automation testing, continuous integration, software engineering practice, Python programming and other areas of original articles.
