Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
What does a developer spend his time on? Writing code, debugging, thinking and communicating with colleagues (that includes meetings). Anything that is beyond these activities is unnecessary overhead (some meetings are also unnecessary, but that’s a different topic).
And yet, depending on our language and tools, we have to do a lot more to support the process of writing code. These activities include, but are not limited to:
- manually format your code – the code has to be beautifully aligned and formatted, but that’s an extra effort.
- using search and replace instead of refactoring – few languages and tools support good refactoring, and that’s priceless in a big project
- manually invoking compilation – compile on save gives you immediate feedback; the need to manually run a compiler is adding a whole unnecessary step to your coding process
- slow compilation – ontop of the previous issue, if your compiler is slow, it’s just a dead time (mandatory xkcd)
- slow time-to-deploy – if the time from writing the code code to running it is more than a few seconds, then you are wasting enormous amounts of time. E.g. if you need to manually make builds and copy files on a local server.
- clunky resource navigation – if you can’t go to a given source file in a couple of keystrokes
- infrastructure problems – you depend on a database, a message queue, possibly some external service. Installing and supporting these components on your development machine can be painful. Recently we spent one day trying to integrate 3 components, some of which had docker instances. And on neither Windows, nor Mac, Docker worked properly. It was painful error-google-try-error-google process to even get things started. Avoid immature, untested tools (not bashing docker here, just an example, and it might have already been improved/fixed)
- OS issues – if your OS crashes every couple of days, your I/O is blocking your UI, you sometimes lose your ALT+TAB functionality (which are things that I’ve been experiencing when using Ubuntu), then your OS is wasting a significant amount of your time.
Most of the manual tasks above can be automated, and the others should not exist at all. If you are using Java, for example, you can have a stable IDE, with automatic formatting and refactoring, with compile-on-save, with save-and-refresh for webapps. And you can use an operating system that doesn’t make you recompile the kernel every now and then in order to keep it working (note: hyperbole here).
It’s often a tradeoff. If I have to compare Java to Groovy in terms of productivity, for example, the (perceived) verbosity of Java is a minor nuisance compared to the lack of refactoring, formatting, etc, etc, in groovy (at least that was the case a few years ago; and it’s still the same with scala nowadays). Yes, you have to write a few lines more, but it’s a known process. If you have immature tools that are constantly breaking or just don’t work (and that is the case, unfortunately), it’s unknown how you should process. And you may end up wasting 10 minutes in manual “labour”, which would kill the productivity that a language gives you. For me Linux was also such a tradeoff – having the terminal is sometimes useful indeed, but it did not justify the effort in keeping the system working (and it completely died after a version upgrade).
Because I really feel all that overhead draining my productivity, I am very picky when it comes to the technologies I use. Being able to type faster or write less lines of code is fine, but you have to weigh that against the rest of the procedures you are forced to do. And that’s part of the reason why I prefer an IDE over a text editor, I don’t use Emacs and I don’t like Scala, andI don’t use Linux.
Your experience may very well be different (and if facebook checking is already taking half of your day, then nothing above really matters). But try to measure (or at least observe) how much time you spend not doing actual programming (or thinking) and have to do “automatable” or redundant stuff instead. And try to ignore the feeling of accomplishment when you do something that you don’t have to do in the first place. And if your preferred technologies turn out to be silently draining productivity, then consider changing them (or improving them, if you have the spare time).
Published at DZone with permission of Bozhidar Bozhanov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.