How to code in the XXI century without losing your head
0 likes108 views
This document discusses how to code effectively in the 21st century without being distracted by unnecessary noise. It identifies several types of noise that can prevent developers from delivering quality products, such as debates over programming languages and frameworks, premature optimization, editor preferences, and testing methodologies. The document recommends focusing on quality over optimization or new technologies, using the right tools for the job, implementing some testing, and agreeing on style guidelines to streamline collaboration. Overall, it encourages blocking out distracting debates and prioritizing effective development practices suited to the project.
How to code in the XXI century without losing your head
- 1. How to code in the XXI century without losing your head @rene_olivo
- 2. The problem with programming today
- 3. Noises that stop you from delivering a quality product
- 4. Quality Product ● Uses the Agile methodology to meet the product needs in a series of timely deliveries ● Can be easily reproduced in dev and production environments ● The codebase is well written and organized which allows changes to be implemented with ease ● Is resilient to changes through testing ● Is built with the precise amount of craftsmanship that suits the product scope
- 5. Types of noise ● Your programming language sucks ● If you are not using this new framework you are doing it wrong ● Your code is not optimized ● Your code editor and keyboard layout suck ● TDD is dead ● OOP is dead, long live Functional ● Tabs, 4 spaces, and semicolons are the work of the devil ● If you don't know math you are a bad programmer
- 7. "Your programming language sucks" noise ● People will always be chewing on you because of your programming language choice. Block that noise. ● Learn when to use the appropriate language for the appropriate task.
- 8. "Out with the old, in with the new" noise (p1). ● Implementing new technologies makes you a digital frontier pioneer. ● Less resources. ● Less tutorials and documentation. ● Harder to put together a team of experts. ● There won't be any "best practices" available.
- 9. "Out with the old, in with the new" noise (p2). ● Unknown challenges after moving on from the "todo" example. ● What's good for Google, Facebook, or Microsoft may not be good for your project or startup.
- 10. "Optimization" noise ● Don't over-invest on optimization. ● Learn about cache, load balancing, replication, and other High Availability techniques. ● Learn about queuing systems and how to connect apps through messaging pipes.
- 11. "Your code editor sucks" noise ● Code is not meant to be written at the speed of light, it's meant to be read with ease. ● Don't fall for the console editors hype, your code editor is fine. ● Learning a new keyboard layout will take time and will yield nothing.
- 12. "TDD is dead" noise ● Stop being lazy, testing is necessary. ● More unit testing, some integration, less E2E.
- 13. "OOP is dead" noise ● People have been killing OOP since the 90s, it's not going to die. OOP has its flaws, but it's the best we have. ● Use functional where it makes sense, don't overuse it.
- 14. "Tabs VS Spaces" noise ● Use a linter and a code editor that supports lint files. ● Find a lint file that suits your project and team and stick with it.
- 15. "Math Envy" noise ● Programming has more to do with Cervantes and less to do with Newton. ● Mastering math helps you solve math problems with ease. ● Math tasks are sparse. ● Data structures are heavily used. ● Algorithm knowledge is more helpful.