I’m really pragmatic on this. To go faster, you need to avoid the things that slow you down. These blockers may vary from developer to developer, but some are pretty common. In this post i will elaborate on the more common ones. Before i do so i want to remind you that to improve, we might need to unlearn in the first place.
Tip: Sometimes, the greatest achievement in improving is to successfully unlearn.
Are you using your Mouse?
Don’t let your mouse slow you down. If you are not using all of your fingers typing, you might want to stop reading here and go over to a typewriting course. The following recommendation also assumes that you are using a feature rich editor like vim or an ide. Every single time you move your hand over to your mouse for a click there is a keyboard shortcut for the exact action that you are not aware of, or not used to. You want to learn these. It’s really not that hard, you’ll get used to it faster than you’d think. Just begin by putting your mouse over to the other (or wrong) side of your keyboard. You’re now forcing yourself to think every time you want to click. When this happens, remember to think of a possible solution using your keyboard. Don’t know any? Ask your friends or search the internet (yes, you can use your mouse for that). BUT: Do not use your mouse for what ever action you wanted to perform. After following these simple rules for a few days, you’ll notice how irrelevant your mouse has become. If you start feeling comfortable using your keyboard only, you could even try some sessions with your mouse plugged out. Mastering your keyboard will significantly boost your development speed.
Tip: You could print out a list of your IDEs shortcuts and use it as a cheatsheet
Reduce the Time debugging
Debugging costs an awful lot. It’s not rare that we end up hunting a bug for hours or even days. Quite often we engage multiple co-workers to solve it. This is really not a scenario we want to be in, since its not only expensive, but also depressing. How can we avoid such a scenario? Pretty easy. Just separate the software into pieces that work in isolation, and write automated tests that cover the components behaviour. This way, we can easily distinguish the component the bug is actually sitting in, and the debugging will become a cinch. The better the tests, the easier to find the bug. However, you wont write good tests, if the system that you are testing is already done and working. You’ll assume that there is no additional value of writing thoughtout tests, when it’s already working. Overcome this dilemma by writing your tests BEFORE the implementation. As a side effect, this will also help you coding in many ways. You want to treat your tests as first class citizens and as what they are – at least as important as your implementation. Think of a blacksmith who’s casting metal into a mold. What would be more important for him. The mold, or the first sculpture coming out of it? You know the answer. And guess what… the tests are your mold. I don’t care what you call it. TDD, BDD or whatever. Just automate tests to cover your softwares behaviour, write them before the implementation, and treat them as what they are – at least as important as your implementation.
Tip: When using TDD, you want to use a shortcut to quickly navigate between the test and its implementation. I’ve bound it to Alt+T
Reduce the Time reading code
I can’t stress this enough: You spend more time reading code than writing code. Believe it or not, while implementing a new feature or solving a bug, you repeatedly read code. You read code before you start writing new code, you read code multiple times inbetween writing code, and you read code after you have written it. Reading a 50 line method is pretty time consuming. Thus you want to make reading as easy and smooth as possible. Write self explanatory code with good names and short methods. And Don’t Repeat Yourself. Who wants to read anything twice? Invest some time on this, and it will pay off.
Improve your search skills
This is an important one. A searchengine has become the most important development tool. It is even more important than your ide. You can do anything without your ide if you can find out how, but you cannot do anything with your ide if you dont know how. You are probably googling regularely, so it’s worth improving. Improve your searchterms. Anticipate helpful words like ‘how to’ or ‘problem’. Try different variants and quote important words and sentences. If you keep getting bad results of a common subject or website, filter them out using a preceeding minus. Here are some examples:
- while c -do -c++
- SomeException -helpme.com
- How to “clean code”
If you keep getting out-dated information, limit your search to the last month/year. This can easily be done in the search options. On stackoverflow, do not always read the first post since its usually a question and code thats not working. Scroll down to the answers with the most upvotes. They are worth reading. Bookmark the sites/docs that you are using regularely. You don’t want to search them over and over again. Also, consider code search engines (Examples here and here).
Focus & Calm
You want to get into and keep a good focus when working on a task. Get into your flow and do not allow disruptions. Several disruptions can easily cost you an hour or two each day. Use headphones in louder environments, and communicate that you’ll be available for questions a little later. Focus requires a clear mind. Make sure you don’t have to remember too much stuff. You don’t want to be afraid of forgetting things. If you can feel the fear to forget, write that thing down – so you can forget. Also, don’t work on too many different tasks/projects at the same time. One is perfect, two is ok. More is probably just slowing you down. I’ve happened to work on 7 different projects a single day. It’s really really dragging from you. Also, stay calm even in the most stressful situation. Huddling just slows you down even more.
Invest in Hardware
Hardware is cheap, workhours are not. Good hardware will save lots of time in the long term. An SSD that makes you boot within seconds and loads everything real quick, saves at least 10 minutes a day which is 40 hours a year. Same goes with ram and cpu of course. Also, screensize really matters. Choose a large monitor to be able to see everything without resizing/scrolling windows/panels. I personally feel comfortable with ~27″. You can speed up many tasks using two monitors also. Web development would be such a task for example.
Tip: 16:9 is standard nowadays but not quite optimal for coding. The higher the screen, the more lines of code you see. Try a 16:10 instead.
Optimize your Workflow, Question your Tools
It depends on what you are working on, but the goal stays the same. You want the most lean workflow and you will constantly have to reevaluate and improve it. For example: If you are working on a Java Webapp, you want to be able to quickly get feedback without redeploying. You can do this by using a class-reloader like spring-loaded or JRebel, or use the Play Framework which does not require redeployments at all due to its architecture. You could also question the language. Is there something else than java that could be more appropriate? Automate everything: testing, building, deployment, notifications. Consider rapid prototyping if you are in the early stages of a project.
