Coding accurately and quickly under time pressure is a valuable skill for any programmer, whether you are working on a deadline, participating in a hackathon, or competing in a coding challenge. In this article, you will learn some tips and tricks to improve your speed and quality of coding, without sacrificing readability, maintainability, or functionality.
Before you start coding, take some time to plan your approach, break down the problem into smaller tasks, and sketch out the logic and structure of your solution. This will help you avoid getting stuck, wasting time, or making mistakes later on. You can use pseudocode, flowcharts, diagrams, or comments to outline your code and make it easier to follow and debug.
First I define the boundaries of the feature or service I need to create. What I can and can not do. It can be what tech stack to use and what patterns I don't want to use for the solution. Then I look for non-functional requirements. What do I need to fulfil and for what do I want to optimise. Service optimised for delivery speed will be different from the one built for performance. This will narrow the pool of possible solutions. Next is describing what needs to be done step by step. Either on paper or in digital format. A quick diagram can be super useful to see how the components fit together. In the last step, especially if it's a complex problem, I like to scaffold the main processes and data structures to validate my assumptions.
Understanding the requirement, scope and design before starting is also important. One more thing which I personally believe is very important is if working in team everyone should be on same page
The primary output of the planning process should be a scope of work that can actually be completed in the time we are given. This applies whether or not we have a short window to work in. One thing we have to be very careful with is understanding that all work comes with time pressures. Whether the deadline is near or far away, the #1 factor that determines this feeling of pressure is the scope of the work to be done. If we want to meet our deadlines the most important lever we can rely on is controlling the scope.
Planning ahead offers clarity, optimizing resources(time and energy) and workflow. This process identifies pitfalls, enhances collaboration, and reduces debugging time. Break down the problem, choose data structures/algorithms, and craft pseudocode. Consider edge cases, devise a testing strategy, and allocate time wisely. Planning is your blueprint for coding success.
1. Get your requirements clarified before starting to code. 2. Write modular code for easy maintenance. Use functions if same thing needs to be repeated again and again. 3. Also if a portion of code is taking more than 5 lines, make it a function. 4. Making functions helps in code modification if requirements change in future or if you have missed considering any case during requirements gathering phase. 5. Keep the variable and function names self explanatory of what they are supposed to hold or the task they are supposed to do.
Coding under time pressure does not mean you have to reinvent the wheel or memorize every syntax and function. You can use tools and resources to speed up your coding process, such as code editors, IDEs, libraries, frameworks, snippets, templates, documentation, and online references. However, make sure you are familiar with the tools and resources you use, and do not rely on them blindly or copy-paste code without understanding it.
For very manual coding tasks there are very good AI tools out there that can increase speed like GitHub Copilot, TabNine, and Amazon CodeWhisperer. You could even code your own IDE plugin to make API calls to tools like ChatGPT to help your productivity (like GitHub ykdojo/kaguya project). Also, is always good to avoid boilerplate code and overloading the project with libraries that we use only a small portion of, but when there's a time limit, consider abstracting part of the work using an external library that could be replaced afterwards. Always have in mind creating abstractions and interfaces to make the replacement easier - in other words, always develop with low coupling in mind.
Timeboxing can help you pace your progress in a consistent manner. An example of that is the Pomodoro technique: spend 25 minutes working on your program without any distractions. After that, take a 5 minute break. That break time could prove useful as you may acquire ideas you haven't thought of earlier.
Incorporating snippets and templates is a masterful strategy – they're like trusted blueprints that can be tailored to the project's needs. I prefer to maintain a personal repository one can utilize gist to manage sinppets or create templates in your favorite IDE . These are like an extension of your expertise, allowing you to efficiently navigate the complex landscape of coding under time pressure. Just remember, while these resources are invaluable, it's crucial not to become overly reliant on them.
You want a large "tool box" of skills and talents to apply to solutions. That said, DO NOT use customer funds to pay for your own "upskilling". The customer needs and deserves the best solution you can produce, so (unless they are onboard with paying for you learning) use tools you are fluent with and that fit the customers needs now and tomorrow.
One of the best ways to code accurately and quickly under time pressure is to write clean and simple code. Clean and simple code is easy to read, write, test, and modify. It follows consistent naming conventions, formatting rules, indentation, and comments. It avoids unnecessary complexity, repetition, and ambiguity. It uses appropriate data structures, algorithms, and design patterns. It follows the principle of DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid).
Create a list of no-go items for ur programming language as part of coding guidlins, discuss with the team and get a buy-in. This way, the code remains maintainable and understandable by everybody in the team. Create templates for anything that could be reused. Like a state machine or a filter.
Clean code helps companies to reduce their tech debt in the future. However, it takes time to follow clean code principles across the company by everyone. It is the best investment for a company to achieve good code quality.
As a "C" programmer I am aware of the tendency of some coders to write overtly concise and barely readable code. That said, writing code where modules fit on one screen is a good rule of thumb for procedural coding. Breaking verbose modules into functions is a great way to reduce visual complexity of code and to provide much greater granularity in terms of understanding.
Writing clean code is akin to a well-organized workspace – it enhances clarity, readability, and maintainability. Embracing consistent naming, formatting, and indentation fosters a harmonious codebase. Minimizing complexity and redundancy amplifies efficiency and reduces error potential. Another principle one can embrace is the YAGNI principle which is akin to cultivating a minimalist approach in your code. It's about exercising restraint, focusing only on the essentials required to meet the immediate goals.
When you're coding with a time limit, focus on making your code clean and simple. Break the problem into smaller parts and tackle them step by step. Use clear and meaningful names for your variables, and keep things straightforward. This not only helps others understand your code quickly but also reduces the chance of making mistakes. Writing clean code might seem basic, but it's like building a strong foundation. It makes your code easy to read, fix, and work with, especially when time is ticking. So, when you aim for simplicity, you set yourself up for accurate and speedy coding, even under pressure.
Another important tip to code accurately and quickly under time pressure is to test and debug your code as you go. Testing and debugging your code regularly will help you catch and fix errors, bugs, and edge cases early on, before they become harder to find and solve. You can use various methods and tools to test and debug your code, such as unit testing, integration testing, debugging tools, logging, breakpoints, print statements, and error handling.
I have found one trick to work for me always. Before I write any code, I write tests for it and add an "assert False" in the body of it. Now my mind enters in a kind of fixing mode and I end up turning all tests green ---> getting a functional code working in all ways I had thought. Writing the tests later might mean missing some cases under pressure.
While under pressure and time constraint, it’s often easy to try to grind through the work, but coding is a meticulous and granular process. That’s why it’s even more important to stay calm and take your code bit by bit, checking everything is working as intended as you continue. The last thing you would want is to find your code full of bugs and errors when you try to compile at the end and have to restart from the beginning. Keeping morale high is essential to any work while under pressure and time constraint, and the frustration of losing progress can be greatly demoralizing. Slow and steady makes quick work over time.
Fast feedback is the big velocity unlock, and testing helps in a few ways: * enshrining the spec in code restates your understanding and helps ensure you're implementing an appropriate solution * as you extend or change the implementation, automated tests give confidence that your implementation holds up * automated tests tend to be much faster and (hence faster feedback!) than manual verification
We can also use some of static code analysis tools such as sonarqube for quick bug finding and standard code practice suggestions
TDD is the great way to test the business logic before it’s going to production. It gives the quick feedback about your code and business logic. There are lot’s of tools for improving code quality like Sonar, Infer, Integration testing, Datadog, Radis and many more.
When you are coding under time pressure, you may not have enough time to refactor and optimize your code to make it more efficient, elegant, or scalable. However, that does not mean you should ignore these aspects altogether. You can always refactor and optimize your code later, when you have more time and resources. Refactoring and optimizing your code will help you improve its performance, readability, maintainability, and functionality. You can use tools and techniques such as code analysis, profiling, refactoring tools, code reviews, and best practices to refactor and optimize your code.
Agile software development's key concept is iterative deliverables. Sometimes we know what would bring the most value to users and that roadmap can be very hard to follow under a strict deadline. If the scope isn't subject to change or the due date can't be postponed, delivering a solution that takes less effort, but brings a lot of value is usually better than not delivering at all. Always future-proof your code and avoid structural decisions that could hugely impact negatively the project in the future. Don't code the perfect feature, code the perfectly iterable solution.
One thing that is really important is to classify remaining deliverables into show stoppers and non show stoppers and do really quality work on the show stoppers. There is only so much you can do in a limited time frame and trying to do all, will most definitely lead to unexpected/unanticipated bugs and application behavior in the future.
I am with Robert Martin here: Refactoring later means it is never going to be refactored. Many things come to place but, if it is production code... make it work then make it right is the minimum practice, but best, do it right in every step even if you are under pressure. Not to do so will have a price later. (I would only skip it, if for sure you do not have business in the later part...)
Agile process seems to introduce problems as it goes. I'm more fond of structured design as modules can be implemented and tested as they are constructed. KLots more control over things. Using SDLC for instance really seems to be the basis of AGILE methodology though it is renamed and rearranged somewhat. I have taken the AGILE classes and really don't see an y advantage over SDLC other than the fact that more people are inherently involved int he project. I have a feeling that is intentional.
When you're coding with time pressure, it's smart to start simple and optimize the code later. Instead of getting caught up in making everything perfect from the start, focus on getting a working solution quickly. Once you have something that works, you can go back and polish it up for efficiency and clarity. This way, you maintain a good pace during the initial coding phase and meet your deadlines. Later on, during the optimization stage, you can revisit the code, figure out where it can be better, and make those improvements. It's a way of balancing speed and quality in coding under time constraints.
The last tip to code accurately and quickly under time pressure is to learn from feedback and experience. Feedback and experience will help you identify your strengths and weaknesses, learn from your mistakes and successes, and improve your skills and knowledge. You can get feedback and experience from various sources, such as mentors, peers, users, clients, judges, or online platforms. You can also review your own code, compare it with others, and reflect on your process and outcome.
Feedback, whether from mentors, peers, users, clients, or even online platforms, is akin to a compass guiding your growth. Comparing your code with others' work is like studying different art forms – it broadens your perspective and exposes you to diverse approaches. Learning and embracing mistakes is as vital as celebrating triumphs – they're like signposts directing you towards greater mastery.
When you're coding under time pressure, it's important to keep learning from feedback and experience. Ask for advice on your code from others, like your teammates or through code reviews. Don't shy away from constructive criticism—it's a way to get better. Learn from what went well and what could've been done differently in past projects. This ongoing learning process helps you refine your coding skills over time. The lessons you pick up from feedback and experience become tools you can use to handle tight deadlines more efficiently and accurately in future coding tasks.
The simplest way to deliver quicker is to do less. Consider carefully what can be left out. Are there features that can be dropped. Do you really need to scale to thousands of users when you have zero users? Can you avoid writing part of the system by leveraging open source or existing solutions? This gives you less to build, less to test, less to maintain and simpler operations.
Delivering under pressure only works if you are confident in what you do. For example, you shouldn't fear deployment because you CI/CD pipelines work and you are confident that they work. Besides that, I agree with @John Crickett that you should do as little as needed when time is scarce. Focus on the relevant parts of the product and skip the rest. In short, keep it as simple as possible.
In this Agile era, I believe prioritizing the task is the first thing we may follow. As per my experience, the code quality may be compromise if we have unrealistic deadlines or goals.
What is transparent is negotiable and, most importantly, not ambiguous - which means there's trust. Time pressure usually means deadlines, which means there are stakeholders following progress. If you are transparent about the progress (report by writing, showing demo videos, reports, screen shots, commits, whatever that would serve as evidence) you can be held accountable and have tools to support decision-making on changing scope, increasing resources on a project or simply postponing a delivery.
Under pressure, my mind is more concentrated on the problem functionally. I don’t know how I used to get those ideas, but I used to write simple and accurate logics with in a short time. My mind is habituated like this. Under pressure I feel I am very good. I can say, under pressure there are few people who will work accurately and give you the best outcome. There are few people, under pressure they will feel tension and get out of control on what they are doing and that type of pressure may destroy the remaining work which already done. Simple trick to work under pressure, we should think about the problem solution rather than taking fear of the problem.