Skip to main content
- Write small, well-named functions, that do one thing well.
- make it work make it right make it fast
- Don’t stick to one technology. If you have been writing only Java or PHP code for 10+ years, chances are that you’ve lost the “big picture”, and your solutions probably are not efficient enough or outdated. Try new tech on your next project!0 replies0 retweets36 likesReply Retweet Like 36 Direct message
- “Learn how to read code, not the comments. Because the comments can lie, but code doesn’t”.
- – pseudocode on paper first – comment your code – learn when to take breaks – compartmentalizing problems and solving one piece at a time will prevent being overwhelmed and paralysis (I’ve learned this one in music practice and transferred it to programming though)
- Start with design don’t start with the code
- “Always code with a piece of paper next to you” very much agree
- The short code doesn’t mean it’s good code! Make it readable, because it will bite back at you.
- Good code is self-documenting 🙂
- Learn the library well before just hopping in & tossing shit together
- seek opportunities to teach, your knowledge will be battle tested
- Get something done. Anything. No matter what. It boosted my confidence in the beginning so much after I saw something that I’ve built finally working. Just try it out and make it work. No matter what. If you fail, try again. You will succeed in the end!
- Clarify the problem you’re trying to solve. So often you end up solving the wrong problem otherwise. There is no such thing as enough documentation. Comments are good, embrace them. Always optimise for code readability first.
- A few more: – wrong abstractions are harder to deal with than duplicated code. Don’t create them prematurely. – code is never perfect. It’s okay to write something shitty & iterate slowly. But it’s important to start somewhere instead of being stuck completely
- Understand the problem first
- don’t take existing code as gospel. i.e. just because it’s there doesn’t necessarily mean it’s correct. question all assumptions
- Make everything reusable right from day one. Now disagree, make it simple and make it work. Only refactor something into for reusability if it will actually be reused.
- – Use proper names – Your classes and functions should have only one responsibility – Don’t comment your code unless it’s strictly necessary – Testing is part of the development Those advices were given to me in my first years of coding and to this day I still agree to them
- The wrong abstraction can be more painfull than duplication.
- simplicity > cleverness
- Agreed. Cleverness is an ego issue. modesty > ego
- 1) Many small daily commits vs one large weekly commit. 2) Put every damn thing you can in the DB so you don’t have to push code to change a label or button text. 3) Be efficient, don’t be “clever”.
- Recently I have learned that creating a document of why you are implementing something and how are you planning to do that with sequence diagrams really helps in getting some initial feedback from all teams and reduces the rework.
- breaking down big tasks into small tasks and solving them sequentially
- 1. Prefer duplication over the wrong abstraction 2. Optimize for delete-ability 3. It’s a “Reader” more than an “Editor” – Act accordingly
- Drawing diagrams is a great way to think things through before you start coding something