What are the 10 tips of a productive developer?

1. Always have a couple of side projects going to keep your mind sharp. When things at work aren’t following you too busy or challenging you sufficiently, spend more time on your side projects during after-hours and weekends. Use your side projects to add new skills to your toolset and experiment with technologies and practices — a luxury you may not have at work, given the usual pressure to get functionality released in the shortest possible time.

 

2. Continuously refactor your code. Once you’ve got something working, with 20/20 hindsight more often than not you can immediately think of a better way to write the same system. Take the time to rewrite the code in a way that makes more sense. Perhaps add the use of a library to do what you were previously doing yourself. The more comfortable you are with the final code, the more likely you are to continue to add new functionality to it and use it as part of your portfolio (put it on GitHub).

 

3. Become increasingly familiar with your development environment and tools. Know your editor like the back of your hand. What’s the quickest way to find a class or refactor a method? What’s the fastest way to modify a text file (learn regex)? Don’t reinvent the wheel. Know all of the libraries available in the language(s) of your choice and how to use them. Force yourself to write an example with each library. Keep those examples handy, so you can review them whenever needed. Once you’re familiar enough with a library, a) you’re more likely to remember to use it when the opportunity strikes and b) you’re more likely to know how to use it and, therefore, resist the temptation to spin your own.

 

4. Read other people’s code. It’s a great way to learn. If you encounter idioms, libraries, patterns or techniques that seem unfamiliar, explore them further until you feel ready to try them in your own code. Being comfortable with reading code written by others is very important for doing code reviews within your team or across teams, working on open source projects, or troubleshooting open source libraries you’re using in your own projects.

 

5. Develop what I call a “pixel to metal” perspective. Eliminate blind spots in your understanding of the entire scope of your application and its execution environment, whether it’s the front end, the back end, the data store, the hardware, supported operating systems, virtualization layers, the network, the data center, or something else.

 

6. Automate. Automate. Automate. Automate everything that you repeatedly do including command line (bash profile), text manipulation and log mining (Perl), refactoring (Eclipse), building, deploying, integrating (Grunt, Ant, Maven, Gradle, Jenkins), testing (xUnit, SoapUI, Selenium, Postman).

7. Don’t optimize.
The impulse to optimize is usually premature. Creative solutions to squeeze performance increase complexity and undermine the end goal. Get the code working. Optimize just that code that needs it, at the end.

 

8. Do optimize for simplicity
You can optimize for execution speed. You can optimize for space. But the most precious thing you should tune for is your own time. Optimize for readability and understandability. If you have to stop and ask yourself, “how does this work?” or “why isn’t this doing what it should do?” — You have just wasted your time.

 

9. Much fancy academic CS is bogus
Some college-based computer science methods should be used with care. Many papers describe techniques which are super optimized around one case. Not all are bogus, but the benefits in many papers are often over-stated. And if you adopt the solution, you may find the benefits do not justify the costs.

 

10. The simplest abstractions are usually best
The real enemy in being productive is the mind of the programmer. The more “cognitive load” you place in your head, the less productive you become. So complexity is the enemy. Whenever possible, adopt simple dumb solutions. He talks a lot about iterating through arrays, rather than smarter data structures. If you can keep it all in your head, you will be faster. You can’t keep it all in your head if there is this ton of complexity.

Me: I think a lot of new programmers like to use advanced data structures and advanced language features as a way of demonstrating their ability. I call it the lion-tamer syndrome. Such demonstrations are impressive, but unless they actually translate into real wins for the project, avoid them.

With each new class/method added to your code, the complexity can increase not linearly but exponentially. Deleting code is therefore always better than adding code. Don’t put stuff into functions when it could be inline.

 

Bonus! Don’t write generalized code
Overgeneralized super flexible code is often a waste of time. It’s usually harder to maintain and a source of potential bugs. Hardcoding isn’t bad if your code is doing one thing.