Writing code can be incredibly taxing from the standpoint of using up mental energy.
This is because it entails a technical challenge intertwined with a creative one. You first have to reason about the specific syntax and constructs of a programming language. Then, you have to design solutions to problems within those technical constraints.
Thinking through layers of abstraction in code should be enjoyable for any developer, of course. But because of how draining it can be, I'd rather write as little of it as possible.
Minimizing the amount of code you write takes proper planning and careful communication, so there is an upfront cost. But the initial work will pay off when it comes to saving time in the long-run by preventing rewrites. Besides, think of all the things you could do with that extra mental energy - like curating your beer palate or debating about which code editor is best (obvious answer - it's this one).
I don't wanna write code all day
To optimize your time and energy as a developer, follow these two strategies to ensure that the code you write counts:
- Know your requirements and their purpose
- Use all of the technical knowledge at your disposal
Using these strategies to their fullest extent requires a certain mindset that's probably different from most developer job descriptions. You'll have to think of yourself as more of a craftsperson who solves problems with code as opposed to someone who just knows how to write in a specific programming language. With this mindset, you can use soft skills to identify and foster stronger relationships between your code and the higher-level problems it's actually supposed to solve.
Why You Should Live and Breathe Your Requirements
Before you write the first line of code for a new feature, you have to have at least a faint idea of what that code should do.
Here's the problem - while having a slight notion of what a feature should do will get you started, it leaves a huge amount of room for error during implementation. In an environment where stakeholders pass down requirements to developers, there are two potential problem areas you have to account for:
- A stakeholder not knowing exactly what they want (or why)
- You not knowing exactly what a stakeholder wants (or why)
Your code should solve a problem such as adding important functionality or enhancing the user experience. These problems are often identified and condensed into general business requirements. They are then usually given to a stakeholder close to the development team, such as a product owner, who can help distill them into technical requirements. These requirements should guide you in your implementation, but they can be a recipe for disaster if they're formed from a shaky foundation.
You may feel like you're doing all the work, but you're still part of a team
If possible, you should always go to the source - speak with high-level stakeholders about business requirements as soon as you can to get an idea of the problems they are attempting to solve. Then, by the time those requirements trickle down to you, you can help shape them into technical requirements.
At this point, you'll have an idea of what the stakeholder knows they want (at this time) and you'll be able to take an important step in solving the first problem above. That is, you'll be able to fill in the gaps in requirements for them and present multiple options for technical requirements. For example, a front-end developer could present multiple options for presenting data from the back-end in a specific UI. Either way, knowing the business requirements will help to form your technical decision making.
This process of getting involved in planning early as a developer can be difficult (or sometimes impossible) in a more corporate work environment. Even if it is, you can always just chat with stakeholders about any projects they're planning. That way, you can get as much of an idea as you can about what's in store for you.
The more informed you are of current requirements, the more informed your technical implementation will be. This prevents you from rewriting code because you didn't know what requirements were or they changed without you knowing.
What about stakeholders that change requirements often? Follow the same advice outlined above while continually communicating with stakeholders. In other words, don't consider the above advice as a set of steps that you just take once. Instead, always try to stay as up to date as possible about what requirements are and what problems they're trying to solve.
How to Channel Collective Dev Brainpower
With the full knowledge of what your code is supposed to achieve, you can now think about your work in a different context. You're not just writing code in a black box to be sent away and reviewed by others. You're writing code as part of a team that's focused on solving certain problems.
This is an important realization as it helps to remove a certain sense of personal ego that could attach itself to your work. It's easy to think of coding in a very personal way - a few code reviews with a defensive developer is enough to demonstrate that. But knowing the bigger picture will help you frame your code as simply a means to an end.
Getting past any personal attachment to your code and instead approaching it in a solutions-oriented way is one of the keys to coding less. This is because it's the best foundation to have when seeking out technical knowledge that will inform your code writing.
Don't be a lone wolf developer and reinvent the wheel when you don't have to
Two important sources of technical knowledge to leverage as much as possible to your benefit are existing libraries, tools, etc. and other developers.
To start, using existing technologies is one of the keys to your productivity as a developer. Ideally, any code you write should directly solve high-level problems. This means that the tangle of boilerplate, build logic, and glue code that's meant to "just get things working" should be kept to a minimum.
In other words, not reinventing the wheel is paramount to writing less code. While learning fundamentals are important, you shouldn't opt to be a minimalist if there are pre-built solutions for your workflow or problem space. As an example for front-end, sticking with just vanilla js instead of leveraging libraries and frameworks meant to increase productivity will usually result in you having to write more code than necessary.
Communicating with other developers about the problems you're working on is also a potential solution to not writing throwaway code. Developers on your team can guide you in your current codebase and point out not-so-obvious legacy issues. They can also provide suggestions for solutions that have (or haven't) worked out before.
In most cases, communicating with your team about the challenges you're facing will speed up your time in development more than any uninformed, solo coding adventure
Asking other developers for help can be painful at first because it entails admitting to others and yourself that you don't know something. It does involve opening up to some extent and being vulnerable. That's why it's important to continue to frame your code as a means to an end. For what it's worth, the best software developers I've met so far in my career are excellent at admitting when they didn't know something and asking questions.
Having a friendly group of developers to work with significantly helps this process. A team of developers that is highly communicative and open to questions will be highly productive. Fostering this kind of culture should be paramount if you care about optimizing your development cycles.
Ultimately, writing less code means writing informed code. Before firing up your code editor, always remember to completely wrap your mind around exactly what problem you're trying to solve and the most productive way to solve it. When your focus is on the high-level problem at hand, the specific implementation choices and details will naturally fall into place.