Programming is a lot like writing — you should start with an “imperfect first draft” that works, and work through it two or three times to solve the problems in the first draft one by one.
Engineers will surely scoff at being flippantly compared to “authors” – but who wrote this morning’s document? Aren’t you “coding”?
Software developers do the most creative types of engineering work. After all, software engineers can be more creative when building applications than civil engineers who build Bridges.
Working in a creative industry means you can learn a lot from the people who write articles. Some of the best writing advice is often recommended to overcome writing difficulties.
Let me suggest some tips for an “imperfect first draft” — because it will help you become a more efficient coder.
Tips for an “imperfect first Draft.
The “imperfect first draft” trick is so common that you’ve probably heard it in your English class, even if you haven’t read the various writing blogs on the Internet.
The key to an “imperfect first draft” is that even if your first draft sucks, you only need to finish the first draft — any first draft is better than a blank page of nothing.
It’s much easier to edit your own work than it is to write it from scratch, so you should immediately try to write something (whatever it is) that will make your code work.
In other words, are you going to write 100 lines of (valid) imperfect code or zero lines of perfect code by lunch today?
The end result, of course, is that you’ll get 50 lines of perfect code done either way. But there is a psychological advantage to writing an “imperfect first draft” : you’ll feel more fulfilled with less stress.
** You’ll have fun coding! What could be more important than this?
How do I start writing a first draft
I prefer to start with a “simple first draft” because an “imperfect first draft” seems like a denial of my coding abilities.
Do you want to be a “bad programmer” who writes “bad code” because you read advice about writing an “imperfect first draft”?
No, you want to be a “successful programmer” who writes “great code” because you’re following the trick of coding from a “simple first draft.”
If you’ve ever copied a code example and adapted it for your own use, you’ve actually learned the trick of a “simple first draft.”
When working with code samples, you inevitably have to make a lot of changes, but the key is to make the code work first and then improve it immediately.
Whether you’re new to coding or an expert, you can use the “easy first draft” approach to any programming task.
Why is a “simple first draft” so useful
When you write effective code, you feel a sense of accomplishment, which puts you in a better frame of mind. Simple code is more likely to succeed the first time you write it.
In addition, simple code is easier to write, thus saving time. Sure, it may seem repetitive and wordy, and your quick-witted brain will beg you to come up with a “better” solution that is simpler and more efficient.
Ignore it
The trick is to have a drink while you’re feeling those feelings, and then go ahead and pursue simplicity. As soon as the code works, you refactor it — once you have a working version, you can make your ideas more complex. But until then, keep things as simple as possible.
Writing coach August Birch calls this “staged writing” : Write the whole thing down, then immediately polish it, refining and revising it in turn.
But programming is different from writing in this respect: because the code must execute successfully, developers know when a first draft is “good enough.” When your code is working, this is a signal to fix the “simple first draft” immediately and refine it several times before moving on to the next step.
For anyone just learning to code, this approach improves two key skills: writing effective code and improving it without breaking it.
Simple code example
I recently mentored a junior engineer through the linkedin platform who was struggling with an overly complex coding challenge. Although this kind of coding challenge becomes less useful once you need to practice it in a real project, it is a good example of how to write a “simple first draft.”
Because the problem was complex, he decided to try to write a complex solution. Let’s take a look at the challenge:
“Write a function, addWeirdStuff, that adds the sum of all odd numbers in arrayTwo to every element under 10 in arrayOne.
Similarly, addWeirdStuff also needs to add the sum of all the even numbers in arrayTwo to those elements in arrayOne that are equal to or greater than 10.
Plus: If you add the elements in arrayOne to the elements in arrayTwo greater than 20, you need to add an extra 1.
It’s worth noting that, just as in real life, he gets an incomplete specification of the requirements: the function addWeirdStuff should return a new array containing items from arrayOne and arrayTwo.
He initially tried to solve this problem with a for loop, but it didn’t work. It’s a complex cognitive task that must challenge one’s working memory (another name for short-term memory), and he can’t do anything about it.
The same person had contacted me about another code problem, because he had accidentally put a return statement inside a complex for loop. He wasn’t ready to write clean code.
I told him that he needed to use two separate for loops and that he should use for simplicity… Of goes through the loop. Here is the JavaScript code and a test to check if his code works:
This code is ugly and poorly written, but it works! And it’s super readable, especially for beginners who are just beginning to struggle with basic concepts.
The next step is to refine this “simple first draft.”
Reconstruction time
Refactoring, whether you love it or hate it, is a process of editing and revising for the authors alone. In programming and other types of writing, it’s much easier to make changes if you’re writing your own text (especially if it’s done immediately).
Use simple language first to reduce the complexity of the text, then edit it immediately. This approach applies to all types of writing, including coding.
I refactor it from the “simple first draft” above:
This is still a challenging problem, and there are many other ways to solve it, but this release is an important step in the right direction.
In the first draft of this release, I added the Reduce function because I prefer to use functional programming in my code
Remember, “The perfect is the enemy of the good. This is just your first draft, you can edit it again! It’s a step-by-step process.
I also prioritized readability over performance because I used.some() for each inner loop. This is an O(n ^ 2) double cycle. For small array matrices, this doesn’t have a performance impact, but it can put you out of work. In the next version of my refactoring, this is not an important optimization.
I decided to make another round of changes using.map() before finishing my “simple first draft” :
This is an “improved first draft”. I will combine two for… The of loop uses.reduce() once,.some() once, and.map() once. I prefer this coding style. But honestly, there was nothing “wrong” with my first draft, because it worked, right?
Now is a good time to switch coding tasks and decide to review the code again tomorrow.
Real coding scenarios applied to
In practice, we often get confused requirements specifications and deadlines, especially when working with new apis. Every coder sometimes wonders, “Why isn’t this code working?”
For the student I supervised, he could never conceptualize a problem to easily solve it, because he went from simple for… The “of” cycle starts. Thanks to the “simple first draft,” he felt successful and accomplished rather than frustrated.
If you’re more experienced and it’s natural to use.reduce() to solve problems, go for it! But if you need to look up the syntax, see if you can refactor the code without looking up the syntax. Because you can always change the code during the coding phase.
Similarly, if you’re using JavaScript, you might want to add type checking to your returns. As a coding challenge, this is not necessary and can be added the next day.
In other real-world scenarios, the downside of the “easy first draft” approach to coding is that you’ll commit Git frequently: at the very least, you’ll need to commit each version of the first draft frequently for step-by-step development. You may have submitted three or four working versions before finishing your first draft.
If you find problems in subsequent work, you’ll be grateful for the many previous commits because you can use them to discover problems and find solutions.
Plus, the number of code submissions gives me a tremendous amount of motivation, especially when I’m working remotely.
test
Depending on your personal preference for testing, you can always write tests before you write code. Just follow the same approach: write tests as simple as possible, and refactor them as soon as the test code works.
Or, like most programmers, you might prefer to test after you have a working piece of code — which is perfectly fine, after writing code and refactoring it once or twice, write some simple tests, and then refactor the test code.
I know that the fastest way to write code is to do exactly the following:
- Write simple code
- Write simple tests
- Refactor simple code with simple tests
- Refactor simple tests
Personally, I find that focusing on an “imperfect first draft” (or “easy first draft,” as I like to call it) makes me more likely to write a test first, because I don’t care if the written test is perfect.
You might even consider testing as a “second draft” of your work and putting it off until tomorrow. Don’t forget to test. Make it all about you, your project, and your company.
conclusion
Whether you’re a novice coder, junior engineer, or expert, if you don’t focus on perfection, you’ll be able to write more code faster. Start with a “simple first draft” and then refresh the code as soon as it takes effect.
Take a page from a technical writer who wrote 100,000 JavaScript articles in 10 programming languages last year — a writing tip that applies to developers and writers alike.
My real advice to programmers at all levels is that your first draft should be repetitive and even feel like a “hack.” First forget the basic coding principles advocated in this article (don’t repeat yourself), then stick to the basic coding rules:
KISS (Keep It Simple, Stupid!)
Once you’ve done that, you can make your code look pretty, but if you have to spend hours debugging, a whole day’s work is wasted — not even getting that code to work. Believe me, I’ve been there!
Also, if you’re just learning a new programming language, development tool, or code base, this advice is mandatory and mandatory.
Happy coding!
🌈 that’s all for today’s article sharing. If you like this article, please like it.Star,Focus onI (public number: front iron egg) 🎯
- Why You Should Make Your Code as Simple as Possible
- Dr. Derek Austin 🥳
- The Nuggets translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: NieZhuZhu
- Proofreader: Yuxiao Alisa Shi, Flashhu, Lsvih