So you’ve already managed to achieve your first programming goals, maybe developed an example application for two. Great! However, it was a bit slow, and a would for sure be much more efficient with it. So now your question is this: how to become faster at programming? professional developer Try to get feedback as early as possible If you are a beginner, it’s safe to assume that there will be many ways to improve your code. If the application works as expected—maybe your solution was a bit hacky. If the approach is OK—maybe you forgot to before committing. Or perhaps you made one of many tiny mistakes , which could be as subtle as using the wrong tense in your commit message. apply a code style while using Git From the perspective of your senior colleague or mentor, it’s impossible to predict what could go wrong. You need to bring your output to a review, and then there, it’s possible to correct the direction in which you are moving. The sooner you reach out for the feedback, the faster the whole process will be. For example: write up how you think the issue can be solved you start changing code before draw of the interface you start building it wireframes before create a merge request for the implementation you update all the unit and e2e tests before A task doesn’t need to be fully completed before you ask for a review. Reviewing things is fast, and if you are lucky, then your colleagues will be able to review before you spend too much time following the wrong path. It’s a writing vs. reading difference—I spend about 3 or 4 hours writing articles, and it’s probably 10 minutes reading time for you. Write fast? Or rather write little? Your job is to solve problems—not to write code. If you can solve problems fast (or faster than you create new ones), then you are doing well in your job. The code output you produce is part of the problem—it will need review, testing, and maintenance over a long time. Learning resources are focused on exposing you to concepts they try to teach you. In the case of programming, they will show you some exercise project or task and make you program to resolve it—without questioning whether it makes sense. Good performance at your job requires you to write code only if there is no better solution available. Question all requests First step: make sure that ‘what is needed’ is indeed needed. Sometimes you’ll get a request to add a feature that shouldn't be part of the system. Or there is already something in place that the user or your colleague who wrote the ticket is not aware of. Or the request is for a ‘nice to have’ thing, instead of something really important. In short—try to understand the requirements well enough to be able to evaluate whether they are indeed necessary. External providers In the end, there is no way to talk your way out of adding features to the system. The next best solution is to find an external provider to do the heavy lifting for you. For example: a cloud provider for turning address input from free-text to a location on a map a complete payment solution—for online or physical stores a mailing service that lets you send emails without worrying about spam filters Integrations are often a headache, but if you find a provider with a good API, it can save you a lot of time on writing and maintaining your own code. User third-party libraries Some tasks are too small to abstract them away from your application and obtain them from an external tool. For many typical and less typical needs, you can find a third-party library that provides some help with these. Libraries come with a trade-off: they provide a solution for some issues require you to learn their API but sometimes bring their own problems and If you pick the wrong library, it can cause you a lot of pain. There are some things about a library that you can evaluate before deciding to use it: the documentation; how the project looks on GitHub; comparisons with other options online. Other things about the library, not so much: what future the library is going to have and whether it will be maintained as long as your project needs it. What kinds of things do libraries provide us: methods for operating on dates money-related features—so you don’t have to worry about result of 0.1 + 0.2 generating charts Reuse your own code You are slowly running out of options. But before you write anything new, make sure it hasn’t already been implemented in your project. Also determine whether some very similar case that already has code can be reused here. Reusing code is tricky—it saves you time when you use the same code in related use cases, but it will create problems if you reuse code for unrelated cases. For example—adding and subtracting works the same for temperature and money; someone introduces support for absolute zero. You wouldn’t like your application to crash as soon as the account goes below −273.15. until Write good code When all that fails—write as little as necessary to fulfill the need, but write it as well as you can. Name classes, methods, arguments, and variables in a meaningful way. Document the code. Write unit tests and some integration tests as well. Add a commit message that explains what is happening in the code and why. In short: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Repeat the whole process Once you are done with the feature you’ve been working on, you are ready to go to the first point and start again. Don’t rush No worries, nobody programs fast. Have you heard the 10x developer myth? Supposedly, some developers are 10 times faster than their peers—maybe there are some geniuses out there, but I’m afraid in most cases people move fast by cutting corners. Taking shortcuts can be necessary in the short term, but doing so creates technical debt that needs to be addressed for the long-term health of the project. Hence the response to this myth: 10x devs are the ones that need 10 devs to clean up after them. Real life Day-to-day jobs are full of situations that could trigger the sensation of being . The other day, I spent 2 hours trying to connect a network printer—and my solution required moving it to a living room. Every so often, I spend hours troubleshooting an issue that was caused by some minor problem—a typo, chasing the bug in the wrong place, or any other . slow stupid mistake Am I hard on myself for those ‘failures’? No. Why? It’s part of the job—sometimes you deliver a solution fast, and sometimes it takes more time. Summary As a junior programmer, your job is to learn stuff and find ways you can help in the project. Every reasonable person understands that learning requires time. In a good workplace, you will receive the support you need to progress and won’t be pressured to develop faster. For me, fast junior programmers sound scary. I would rather have a slow junior colleague that gets things right eventually. Fast learners, responsive to feedback—that sounds great. But one that just pumps out changes quickly—not so much. Also Published Here

HTML + CSS Practice Project: Website Slicing

The README file: How to Help Others Understand Your Project

Newsletter

Too Long; Didn't Read

Make resilience your competitive advantage

Your Guide to Becoming a Faster Programmer

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Long-Term Benefits of Unit Testing (With Jasmine Examples)

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

The Long-Term Benefits of Unit Testing (With Jasmine Examples)

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps