21–30 of 191 posts
Taking the time to properly understand the concepts, protocols, formats, apis and tools that you use when working on something.
This I never seem to have the time or mental energy to do.
A few habits I've found that work well for me: 1. Start small, then extend. 2. Change one thing at a time. 3. Add logging and error handling early. 4. All new lines must be executed at least once. 5. Test the parts before the whole. 6. Fix the known errors, then see what’s left. Taken from here: https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...
1. If at all possible start from something existing. It is entirely possible by the time you are done nothing remains of the existing. That's fine. To me, it's easier to tweak existing code than fill in an empty editor window. To some, an empty editor window is all opportunity, to me, it's analysis paralysis.
2. Always be ready to throw everything away. You perhaps will save a few choice lines but be ready for your first, sometimes even the second solution to suck badly. This is fine. Putting in more time to have an easier to maintain solution is always useful.
3. To continue from there, easier to maintain code is king. Unless you are writing something extremely time critical do not try to be clever. A little slower is okay (and yes, I am in the performance consultancy business) if it significantly decreases the maintenance burden. Clever hacks belong to toy projects and blog posts. The next person who maintains it will be stupid to the code -- even if it's yourself. That clever hack is now a nightmare to untangle. In short: always code under the assumption that you will need to understand this when the emergency phone kicks you out of bed after two hours of sleep in the middle of the night. The CTO of Cloudflare was woken to the news of Cloudbleed at 1:26am.
See videos like Gary Bernhardt - The Unix Chainsaw on how he gathers very nice data on just about anything in his system with a few pipes. It's easy to try to be awesome in OOP, or in javascript but waste time and energy clicking around or digging manually in repos for information.
I find that is the nicest and most efficient advice I ever took.
The other habit is: improving your maths skills (sophisticated combinatorics, probabilities, statistics) ..
http://bookofhook.blogspot.in/2013/03/smart-guy-productivity...
Spend at least as much time evangelizing what you have developed and promoting it to others as you spent developing it. Otherwise even the best code will risk ending up in a trash can.
Study the idioms of whatever language you are using. If you're writing production code, consistency is everything. Don't write anything surprising or clever - you'll just paint yourself into a corner later, and it'll be impossible to maintain. Boring code is good code. Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mys…
Focus on the problem and not the tools ceremony around it. Don't follow the herd and the hype. When given a problem, keep drilling the problem until it is absolutely clear to you and then only work on solution.
This. I often encounter situations where a day or two were spent creating a mess of classes and abstractions, yet the actual logic to solve the problem still hasn't materialised. A defense about "code quality" or "not wanting to write spaghetti code" is often made. My recommendations for a problem you don't have a clear solution in mind for: 1) Hack some pseudo-code spaghetti together in a blank file until you think…