Download to read offline
More Related Content
Similar to 30% faster coder on-boarding when you have a code cookbook
30% faster coder on-boarding when you have a code cookbook
- 1.
- 2. Instructions for use GUIDELINES Followthe chapters and try to apply. Ask where you can’t find something. DON’T SPEED READ We did a lot of copy/paste to make this presentation. Take the time to soak in the knowledge. Feedback is always welcome DON’T BE LAZY If you are here, you are some sort of expert in whatever, but don’t be a lazy one. Read our presentation and follow the rules. OUR ARCHITECTURE Check out our stack on stackshare.io 2
- 3. 1. Quality Matters Always code asif the guy who ends up maintaining your code will be a violent psychopath who knows where you live. 3
- 4. Let us changeour traditional attitude to the construction of programs. Instead of imagining our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do -- Donald Knuth 4
- 5. Programs must bewritten for people to read, and only incidentally for machines to execute Ă— isolate complexity as much as possible Ă— do not add new functionality unless an implementer is otherwise unable to complete a real application without it Ă— the only thing worse than generalizing from one example is generalizing from no examples at all Ă— write new code only when everything else fails 5
- 6. 6 Don't do hardthings, do easy things Ă— Simple is better than complex. Ă— Complex is better than complicated. Ă— Flat is better than nested. Ă— Readability counts. Ă— If the implementation is hard to explain, it's a bad idea. Ă— If the implementation is easy to explain, it may be a good idea.
- 7. Plan "Plans are worthless,planning is invaluable." -- Sir Winston Churchill 7
- 8. Teach Teach everyone howyou managed to finish your task. Prepare a short explanation about your thinking pattern. Don’t assume. Give away your knowledge. Programming is also Teaching your team Learn When your teammate finished something, ask how he did it. You see a nice syntax, ask why that? Ask an annoying amount of questions. 8
- 9. Think in cycles FunctionalFirst Build small features and make sure they work. Test your edge cases! Add Functionality Now add another feature and make it more interactive. Every new feature should work seamlessly ...but not too big Create the basic functionality and wait for someone to ask you for more. Basic as in: 5 features is enough! 9
- 10. Ask 1000 questions Not literally1000 but still, ask the obvious questions, ask even if you know. Ask to clarify the task. 10
- 11. Use drawings to explainyour plan 11 Draw before Coding Take 10 min and show us the team your inner da Vinci so they get what you want to achieve. You will be surprised how much insight an ugly drawing can bring to your own concept. We always use Google Drawing.
- 12. 2. Tools and Communication Some oldChinese guy once said “The tool is half the job”. True, but only if you use it correctly. 12
- 13. 13 GitHub Ă— use branchesfor features, AB tests, fixes or whatever Ă— commit often Ă— the clearer the commit message, the better Ă— always use pull requests, always Ă— backups are important, keep master releasable
- 14. 14 Trello Ă— think aboutthe workflow for your board Ă— keep card titles short and sweet Ă— use markdown to improve readability Ă— use checklists Ă— always update your tasks
- 15. 15 Slack Ă— keep Slackopen at all times Ă— respect the channels Ă— share what you think is beneficial for the team Ă— integrate with other tools: github, trello, gdocs Ă— snooze Slack all afternoon so that you can stay focused on work without being notified every five minutes
- 16. 3. Tasks and Time Management “Thereis no exercise better for the heart than reaching down and lifting people up.” ― John Holmes 16
- 17. The two hour Rule Ifyou just stare at the screen and scratch your head, you need help 17 If you’ve been staring at the screen for two hours and still can’t figure out how to do your task, stop and ask for help
- 18. 18 Ask For Help �when you can’t figure out how to do your task � when you feel it’s too big of a challenge for you � when the solution you want to implement is not elegant � when adding if/else seems the only way � when you need to confirm something before coding � whenever you need!
- 19. 4. Code Contribution "What one programmercan do in one month, two programmers can do in two months." -- Fred Brooks 19
- 20. Code for the Future Accept thatyou have no idea how this will grow 20 The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don't know everything, you begin to design the system defensively... You should spend most of your time thinking about interfaces rather than implementations. -– Nicholas Zakas
- 21. 21 When we sayalways, we mean always Ă— always triple-test before commiting Ă— always write function documentation Ă— always typecast Ă— always test edge cases Ă— always respect tslint Just adding if/else makes the code function, but there are far better ways. Always code for others to understand. Always.
- 22. Don't Write Code, yet Checkfor Duplicates Reducing the amount of code in your product should be a goal. Follow Naming Conventions User class is a for a user. You can’t add a validateOrder function. Use the order class Keep Lean Dependencies Npm has a lot of good packages and even more shitty ones. Add a dependency only when it’s absolutely needed. 22 Stop Writing Classes We have interfaces, decorators and functions. Write what makes sense, not what you are comfortable with Reinvent the Wheel Yes, you can. Upgrade your libraries, create your boilerplates, publish and perfect them. Rewriting > Patching If you are changing more than 25% of a class or method, consider simply rewriting it. You will write the code more cleanly
- 23. Application Logic Libraries arenot Apps Avoid mixing object creation with application logic. Don’t limit your classes to application logic Good Naming Anyone should be able to understand what the function does, not just coders. Extended Naming If main function is named create() than extended functions can be createOrThrow(), createAndLogin() 23 Document Conventions If the class should be used ONLY in a particular way, write about it. Use an @example and @configuration to let everyone know how In-Code Documentation Write your docs in the code directly. Check the generated docs. Is it clear enough? Easy enough? All cases handled? Good! Later Means Never “I’ll document later” No, you won’t. Do it now. Change it later if you need to, but train yourself to play by the rules.
- 24. Templates are Landscapes, not Puzzles 24 MasterTemplate Build a beautiful master template with all the elements you need. Play around with static elements, but always make it beautiful Copy/Paste Psycho Elements from your template should be copy/paste ready. Don’t add static data, make an example interface. Describe what they should be used for Styling Don’t just add style=”” on your <div>. Try to find something in the template that fits, an existing class, a bootstrap class. Don’t be lazy!
- 25. Commit and pullrequest in the morning, before 10 AM Writing code can be exhausting. A good night's sleep always helps you see things clearly. We expect you to commit your work before 10am the next day. 25
- 26.
- 27. “Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts only): Don't do it yet” -- Michael A. Jackson 27
- 28. 28 ďż˝ Design forperformance from day 1 ďż˝ Profile often ďż˝ Be vigilant on performance regressions ďż˝ Understand the data ďż˝ Understand the hardware ďż˝ Help the compiler ďż˝ Verify your assumptions ďż˝ Performance is everyone's responsibility
- 29. 29 Better With Every Change �eliminate dead code � strengthen reduction � common subexpression elimination � move code to structure � reduce dependencies as much as possible
- 30. Documentation is an obligation 30 Codewith no documentation is only half done. We know it has been hard to write but it doesn’t have to be hard to read
- 31. 6. We Love Open Source Ithink, fundamentally, open source does tend to be more stable software. It's the right way to do things. -- Linus Torvalds 31
- 32. Good artists copy;great artists steal -- Picasso So copy/paste and upgrade 32
- 33. Think Long-Term How tochoose what library to use � has good community support (Github 🌟) � is updated constantly � licensed under Apache2 or MIT � plays nice with our stack � is absolutely necessary! 33 “I found an awesome git repo that solves ALL our problems”👩
- 34. 34 Do You Even Open Source, Bro?! Goto our git Sounds weird when you say it out loud, but we love it! We are committed to open source. Let’s build awesome things and give them for free!
- 35. 7. Rome Wasn’t Built ina Day A coder is a student who’s homework is never done, no matter how hard she works 35
- 36. 36 ďż˝ Store configsin app.module ďż˝ Keep business logic separate Decouple in 24h! All our modules should be easy to separate into a separate service
- 37. 8. Don’t Forget About theHuman Programs must be written for people to read, and only incidentally for machines to execute 37
- 38. Feelings Matter 38 Stop thinking abouthow it looks to you and focus how it makes others feel. That’s magic!
- 39. 9. You can’t beKant and don’t try to be Always have good questions prepared. We love questions! 39
- 40. The 7 C’sof Effective Communication � Completeness - the communication must be complete � Conciseness - conciseness means wordiness � Consideration - take the audience into consideration � Clarity - exact, appropriate and concrete words � Concreteness - leave no room for misinterpretation � Courtesy - respect the receiver � Correctness - no grammatical errors in communication 40
- 41. 41 Grammar: the difference betweenknowing your shit and knowing you’re shit
- 42. 10. Random Wisdom Don't becomea philosopher before you become rich! -- Shah Rukh Khan 42
- 43. Customers Will Remember How YouHandle Edge- Cases 43 If there are 2 buttons, both work, but if you press the first one, the 2nd loses its action. Nothing else matters. “Your system sucks!”
- 44. What Does This ButtonDo? 44 Dummy features should only be visible in development mode. Customers will always find what you never thought of clicking
- 45. failure is aninnovation too small to sell -- Gabriel 45
- 46.