They invest in good documentation
- Document your code as you go, not after.
- Documentation is like salt. Too little and you create knowledge gaps throughout your team, too much and you create unnecessary overhead.
- The Most Important Code Isn’t Code
I typically hate process. From TDD to BDD to Agile to everything else, it usually feels too cumbersome for me to stick with it. But two mentalities have really impacted me: TomDoc and Readme Driven Development. Both were designed by Tom Preston-Werner. Both have documentation at their core. Though they’re both obviously helpful for other developers who look at your code, I’ve found them to be extremely helpful to me as I code.
Documentation is Marketing. A good README gets people to jump into your project much, much quicker. Heavily-documented code means others can read your project much, much quicker. Heavily-documented code means others will tend to break your tests less.
They watch conference videos
They actively prototype new ideas
Effective engineers don’t just read or watch tutorials—they build.
- Prototyping helps you discover what works and what doesn’t, fast.
- Prototyping is about Proof of Concept (PoC), even if they’re rough or incomplete.
- Prototyping is a low-risk way to test ideas and get immediate feedback before committing significant resources.
They are lifelong learners
A key trait of a good programmer is the ability to learn new things. While you can never know everything, the ability to rapidly absorb / pick up new concepts and tools from available online resources enables you to stay well-informed and adaptable.
They are incremental and iterative
Code Reviews
-
Quick and timely code reviews. Begin your day with code reviews (to unblock your peers).
-
Ensure that each Pull Request (PR) out for code review solves one problem, and is small and targeted.
This also applies to the Git commits.
#TODO
Productive Developers are Smart and Lazy
Make a plan before diving into coding!
Productive developers are constantly checking their understanding of the requirements and making sure that they are staying in sync with their team’s code. Productive developers are in regular contact with the product managers/business analysts and can often be seen white boarding with their peers and architects.
Good development is lazy development a.k.a. patient development; it happens when the developer spends the time necessary to think through all the pathways of the solution that he is developing BEFORE writing the code. That is lazy-writing of code, i.e. not writing code before the problem is understood. The more due diligence (審慎調查、盡責查證) a developer does to make sure that he is writing the correct code will reduce the amount of code that needs to be written.
It is a bad sign if developers are always coding. If you see developers spending 100% of their time staring at their screens with no human interaction then you are looking at some of the worst developers.
When in doubt, be lazy and write code late. (懶惰式/忍耐式開發)
Implement all the basic collection types (data structures) at least once.
- Dictionary
- Sorted Dictionary
- List
- Linked List
- Stack
- Queue
Learn a functional programming language.
Get good with the debugger. Set breakpoints on code you don’t understand. Step through it, watch the data as it flows through each method. If you don’t understand something, look at the docs for that specific concept until you get it.