So you've already accomplished your first programming objectives, perhaps by creating an example application for two. Great! It was, however, a little slow, and a professional developer would undoubtedly be much more efficient with it. So the question is, how do you become faster at programming?
Try to get feedback as early as possible
If you are a beginner, it is safe to assume that there will be numerous opportunities to improve your code. If the application works as expected, perhaps your solution was a little sloppy. If the approach is correct, perhaps you neglected to apply a code style before committing.
Perhaps you made one of many minor errors while using Git, such as using the incorrect tense in your commit message. It's impossible to predict what could go wrong from the perspective of your senior colleague or mentor.
You must submit your output for review, and only then will you be able to correct your course of action. The sooner you solicit feedback, the faster the entire process will be. For example,
- write up how you think the issue can be solved before you start changing code
- draw wireframes of the interface before you start building it
- create a merge request for the implementation before you update all the unit and e2e tests, create a merge request for the implementation.
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 of reading time for you.
Write fast?
Or should I say, write a little? It is your job to solve problems, not to write code. If you can solve problems quickly (or faster than they are created), you are doing well in your job. The code output you generate is part of the problem—it will require extensive review, testing, and maintenance over time.
Learning resources are designed to expose you to concepts that they hope to teach you. In the case of programming, they will show you an exercise project or task and instruct you to write code to solve it—without questioning whether it makes sense. When it comes to your job, you should only write code if there is no other option.
Question all requests
The first step is to 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 maybe 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 store 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 from 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
- but require you to learn their API
- and sometimes introduce their own problems.
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; and 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 with?
- methods for operating on dates.
- money related features—so you don’t have to worry about the 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 cases that already have 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 use cases. For example, adding and subtracting work the same for temperature and money until someone introduces support for absolute zero. You wouldn’t like your application to crash as soon as the account goes below 273.15.
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 back to the starting point and start again.
Don’t rush
No worries, nobody programs fast. Have you heard of 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: The 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 slow. The other day, I spent 2 hours trying to connect a network printer—and my solution required moving it to the 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 stupid mistake.
Am I hard on myself for those "failures"? No Why? It’s part of the job—sometimes you deliver a solution fast, sometimes it takes more time.
Summary
As a junior programmer, your job is to learn new things and find ways to contribute to the project. Every reasonable person recognizes that learning takes time. In a good workplace, you will be given the support you need to advance and will not be pushed to do so.
Fast junior programmers frighten me. I'd rather have a slow junior colleague who eventually gets it right. That sounds fantastic. Quick learners who respond well to feedback But one that simply produces changes quickly—not so much.
Post a Comment
Post a Comment