“The Father of Keras”, a software engineer’s growth checklist

Code is not just meant to be executed, it’s also a way of communicating with the team. We can use code to describe solutions to problems to others. Readability includes clear paragraphings, easy-to-understand variable names, and comments that describe what is implied. Readability isn’t icing on the cake, it’s a necessary attribute for writing code.

Instead of thinking about how this job will help you get promoted, think about what you can do for your product’s users and community. Avoid “visible contributions” at all costs. Don’t add features that don’t really help your product.

Personal taste is reflected in the code. Taste is a constraint – the desire for simplicity systematizes the taste of this construal satisfaction. Keep it simple.

Smells also apply to code. Taste is a constraint – a balance between satisfaction with process and desire for simplicity of code. Keep your preference for simplicity.

Learn to say no. If someone asks to add new features to the code, we have the right to say no. In fact, each feature costs more than originally thought: maintenance costs, documentation costs, and user perception costs. Whenever asked to add code features, ask yourself: Should we really be doing this? Generally speaking, the answer is no.

When you decide to add new use cases to your product, it is important to note that you will not achieve the best results if you add content literally to the user’s request. Users are focused on their own specific use cases, and you have to think in terms of the project as a whole and principles. In general, we should extend existing functionality rather than add a very piecemeal module.

Invest in continuous integration and comprehensive code unit testing. Always make sure you’re in an environment where you can confidently code; If you can’t have a decent environment, you have to build the right infrastructure first.

You don’t have to prepare everything in advance. Sometimes it’s good to try it first, see what happens, and then change the bad try early. Make sure you set up an environment where you can do all of the above.

Good software makes things easy. Just because the problem seems difficult doesn’t mean the solution has to be complex or difficult to use. Too often, when we have an easier and less glamorous solution, engineers choose to use a more complex solution with side effects (voiceover: “Let’s use it

“! “Let’s build an app!” “Let’s add

!” Before writing any code, make sure you choose the simplest solution. Start with simplicity first and offer a solution.

Avoid all implicit rules. If you find hidden rules in your code, comment them out and share them with others or automate them. Whenever you discover a repeatable, algorithm-like workflow, try to document it so that other team members can benefit from your discovery. In addition, you should try to automate any part of the workflow (such as correctness checking) in your software.

Think about the impact of your code changes throughout the product design process, not just what you want — like revenue or growth. Beyond the specific metrics you’re monitoring, what is the overall impact of your software on users around the world? Are there any side effects? What can you do to fix these problems while preserving the usefulness of the software?

Your API has users, so it’s a user experience. Keep the user in mind with every decision you make. Put yourself in the shoes of your users, whether they are beginners or experienced developers.

Minimize the cognitive burden of using the API. Automate automatable content, minimize the number of actions and choices required by users, don’t expose unimportant options, and design simple and consistent workflows that reflect simple and consistent mental models.

Keep simple features simple and make complex features possible. Don’t increase the cognitive cost of common features to implement a particular feature.

If the cognitive cost of the workflow is low enough, users should be able to remember it after completing it once or twice (without having to revisit the tutorial or documentation).

Seek apis that match the mental models of domain experts and practitioners. Someone with domain experience but no API experience should be able to intuitively understand your API with minimal documentation. They mainly look at code examples, available objects and their signatures.

Even without any material on the underlying implementation,

The meaning of “should also be easy to understand. Specified by the user

It should be about the user’s mental model of the problem, not about implementation details in the code. An API is only about the problem it solves, not how the software runs in the background.

The most powerful mental models are modular and hierarchical: concise overall, precise when you look at the details. Similarly, a good API is modular and layered: easy to get started, but expressive. There is a balance between using complex signatures on fewer objects and using simple signatures on more objects. A good API has a reasonable number of objects and a reasonably simple signature.

Your API inevitably reflects your implementation choices, especially the data structures you choose. To implement intuitive apis, you must choose data structures that naturally fit the domain. This matches the mental model of experts in the field.

Thoughtfully design the workflow from start to finish, not just a set of atomic functions. Most developers approach API development by asking “What functionality should be provided? Let’s configure options for them.” Instead of asking, “What are the usage scenarios for this tool? What is the optimal sequence of user actions for each usage scenario? What is the simplest API to support this workflow?” Atomic options in the API should meet the explicit requirements that arise in high-level workflows. “Because someone might need it” is not an added reason.

Error messages, as well as any feedback typically provided to the user during interaction with the API, are part of the API. Interactivity and feedback are integral parts of the user experience. Design API error messages carefully.

Because code is meant to communicate, naming matters — whether it’s naming items or variables. The name reflects your view of the problem. Avoid overly generic names (such as “x, variable,

“), avoid overly long and specific names, avoid terms that could create unnecessary disputes (e.g. “slave owner/slave”), and ensure consistency in naming choices. Naming consistency means internal naming consistency (for example, using both “dim” and “axis” when not naming “axis”), as well as established convention consistency with the problem domain. Before settling on a name, be sure to look for existing names used by domain experts (or other apis).

Documentation is at the heart of the API user experience. It is not an add-on. Take the time to write high-quality documents, and you’ll see a higher return than spending time on other features.

Use “Show” instead of “tell” : Your document should not talk about how the software works, it should show how to use it. Code examples that show the workflow from start to finish; Shows code examples for each common use case and key functionality of the API.

Career advancement isn’t about the number of people you manage, it’s about the impact you make: whether your work makes a difference in the world.

Software development is about teamwork, and interpersonal relationships are as important as technical skills. Be a good teammate. As you go down your career path, keep in touch with others.

Technology is never neutral. If your work has any impact on the world, that impact has a moral direction. Our seemingly harmless technological choices in software products adjust the terms of technology acquisition, the incentives for technology use, who will benefit and who will be affected: technological choices are also ethical choices. So always be careful and clear about the values you want to support by choosing to do so. Design for ethics and incorporate your values into your creations. Never think “I’m just building this functionality, which is inherently neutral” : it’s not, because the way you build it determines how it will be used.

Build what the world needs, not just what you wish you had. Too often, techies live separate lives, focusing on products that meet their specific needs. Seek opportunities to expand your life experience so that you better understand the needs of the world.

Put your values above short-term self-interest and emotions, such as greed or fear, when making any choice with long-term consequences. Know what your values are and let them guide you.

When we find ourselves in conflict, it’s a good idea to pause, acknowledge our shared values and common goals, and remind ourselves that we’re almost certainly on the same side.

Productivity boils down to high-speed decision making and action bias. This requires: 1.) good intuition from experience in order to make broadly correct decisions with partial information; 2.) Be keenly aware of when to act more cautiously and wait for more information, because wrong decisions cost more than delayed ones. The optimal speed/quality decision trade-offs can vary widely in different environments.

Making decisions faster means you make more decisions throughout your career, which will give you a stronger intuition about the correctness of possible options. Experience is the key to productivity, and higher productivity will give you more experience. It’s a virtuous circle.

In situations where you recognize a lack of intuition, stick to abstract principles. Establish a solid and true list of principles throughout your career: Principles are formalized, intuitive, and primitive

(requires direct and extensive experience of similar situations) can be generalized to a wider range of situations.