Summary

The context provides tips for improving productivity in programming, focusing on starting with UI or test case development, knowing when to write bad code, utilizing copy-paste techniques, and emphasizing the importance of continuous learning.

Abstract

The article titled "How to Be a Productive Programmer" discusses various strategies for improving productivity in programming. It suggests starting with UI or test case development, as it allows for early validation of ideas and provides a sense of progress. The author also emphasizes the importance of writing "bad code" when experimenting with novel ideas to validate core concepts. They advocate for being generous with copy-paste techniques, as it allows for efficient implementation of common functionalities. Lastly, the article highlights the importance of continuous learning and reading, as it leads to improvements in code quality and overall career growth.

Opinions

Productivity in programming is often defined as getting more story points done, as defined by the tech lead, within a given timeframe.
Beginning with UI implementation or test case development can lead to a sense of progress and allow for early validation of ideas.
Writing "bad code" is encouraged when experimenting with novel ideas to validate core concepts, as it can lead to motivation and a sense of accomplishment.
Copy-paste techniques are seen as essential for efficient implementation of common functionalities, as they allow programmers to focus on more critical aspects of development.
Continuous learning and reading are considered crucial for improving the quality of code, contributing to team discussions, and advancing one's career.
Programming workplaces that discourage reading as a non-productive activity may not be worth working for.
Productivity in programming should never come at the expense of one's personal life.

How to Be a Productive Programmer

Learn to deliver better quality code in better time

Productivity in programming is a misleading concept. Veteran coders often define productivity as getting more things done with fewer lines of code. Performance freaks warn against boilerplate code which abuses computing power in a race to get more done.

For an average coder, programming productivity boils down to just one thing: Getting more story points done as defined by their tech lead, at least by Friday.

In a 9–5, five-day workweek with daily stand-ups, that’s what gives you a sense of accomplishment: smooth demos, and not-so-bad feedbacks—no matter how many regressions it produces three months afterward.

So here are some programming productivity tips to prevent those humiliating moments when you have to overwork to compensate for prior lapses.

Always Begin With UI/Test Case Development

If your project involves UI, beginning with UI implementation at the start of feature development always pays. No matter how much you argue against it, UX decides its value to the users.

But there’s a UX person on the team — isn’t this their responsibility?

Absolutely. But a working demo always triggers second thoughts in a team’s collective psyche. People, by nature, tend to find areas of improvement upon a second look.

Unless you wrote 100% decoupled code, a UI change will mostly trigger view-model change, which may cause major rewriting of modules/classes.

UI development also allows stakeholders to have a sense of early validation of their ideas. It gives the whole team some sense of progress, which gives you, the feature developer, some room in forthcoming sprints. You can utilize this stress-free time to develop the model and networking parts.

If there is no UI, you will do well to start by doing test case development. The benefits of TDD are hailed across the industry, and you will surely reap its rewards later in the development cycle.

…Except When You Should Begin With Writing Bad Code

How would you start on a novel file compression tool if you had never zipped a file programmatically?

UI is out of the question here. Tests are helpful, but may not give you any sense of accomplishment/validation at first.

What you need here is not productivity, but some force that will drive you through this novel development. Some motivation.

A belief that this can be done. And you can do it.

Validate the core idea first, without caring about UI/tests/function parameters. Measure your results:

How time- and space-efficient is your compression algorithm, compared to gzip and its peers?
How much would the industry pay to choose it over freely available solutions?

Discuss your findings with your team. Give them something to boast about in Friday coder parties or investor summits.

It doesn’t really matter at this stage if you hardcoded your COMPRESSION_QUALITY_RATIO, or skimped on file-size validations.

The key factor here is not successful completion or sophisticated implementation, but being in a position to decide whether you can do it, and whether the team can go with this tool/approach to buy more time to make an MVP.

Be Generous With CPC (Copy/Paste/Clone)

A generation of programmers has popularized the idea that a developer who has to copy-paste code from StackOverflow or GitHub isn’t a good programmer.

They belong to the paper-trail generation when there wasn’t enough Internet. At the same time, they also rarely worked on diversified technologies/languages. So they worked hands-on, right from the API docs.

The thing is, in order to be efficient in the things that matter most, all effective coders heavily rely on copy-pasting common functionality.

A file-writing code snippet copied from the StackOverflow top dev’s answer will be 1000 times better than your own version conjured up from reading horrible docs.

Of course, your talent will shine through in deciding whether to invoke that file-write from UI main thread, a background thread or to eliminate it through some caching.

Again, copy-paste that backgrounding/caching code from somewhere else, and put them together.

All great chefs have gone through this. After some years, you will be in the perfect position to come up with your signature recipes.

Read, Read and Read

If I had 8 hours to chop down a tree, I would spend 6 of those hours sharpening my axe.

— Traditional

When browsing tech stories about development, you’ll see that learning important programming concepts is as important as completing your story points in time.

Knowledge about industry best practices leads to exponential improvement in:

Quality of code you produce
Ideas you discuss in meetings
Your long term career
The tech world at large

If you have to deliver a feature at Thursday’s stand-up meeting, you should spend your entire Monday reading about it, without even writing single line of code.

Make Google your friend. Try different search combinations surrounding the topic, the libraries and frameworks involved, and the deeper concepts.

For example, if you had to write an authentication module for a website, your online reading must include OAuth, Passport and other third-party modules, and password encryption.

Copy/paste/clone should ideally begin on Tuesday evening, or even Wednesday morning when you are completely familiar with the concepts, code snippets, and callbacks.

By that time, you’ll be in a position to copy-paste from the best source.

If your team/tech lead disapproves of it even within acceptable limits, it’s a red flag about your career in the current company. Follow this strategy:

Disobey them by continuing to read. If you want to avoid confrontation, peruse your programming book in transit.
Of course, office-time suggested research does not include watching your favorite celeb’s Instagram feed unless you’re developing an Instagram competitor. That’s the perfect excuse.
Keep delivering.
Go on job interviews, and jump ship when you are leveled-up enough from your reading.

A programming workplace that sees reading as a non-productive practice is not worth working for.

Conclusion

Unlike other industries where production can be measured in units per hour per worker, programming productivity has no universal standards. Sprints help us define it, but are still quite subjective.

Following certain efficiency techniques helps you boost estimation power. With better estimates, you can deliver better quality code in better time. Always remember that productivity should never include sacrificing your personal life.

These programming productivity tips are just a start. As you grow in experience, cultivate your personal best with constant experimentation: experimentation with your tasks, with your colleagues, and most importantly, with your habits.