开源日报 - Page 132 of 262

开源日报第516期：《MC mc.js》

13 8 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《MC mc.js》
今日推荐英文原文：《20 Things That Are Good to Know When You Start Web Developing》

今日推荐开源项目：《MC mc.js》传送门：GitHub链接
推荐理由：Minecraft 是个超自由的游戏，但是要在电脑上启动它似乎还是没那么便利的，这个项目就解决了这一点——浏览器！MC！最佳组合！在浏览器上也能运行的 MC，足以让你方便快速的安利给其他朋友们（当然了，要等它发展到完全版），不过随着这个项目的发展，总有一天能追上 PC 端的版本。
今日推荐英文原文：《20 Things That Are Good to Know When You Start Web Developing》作者：Daan
原文链接：https://medium.com/better-programming/20-things-that-are-good-to-know-when-you-start-web-developing-82f6c81b84a
推荐理由：从零开始做 Web 开发者的心得指南
20 Things That Are Good to Know When You Start Web Developing

When I started with web development, there were a lot of things that I didn’t know that would have been good to know. In hindsight, a lot of the expectations I had weren’t even close to the real situation. In this piece, I’ll tell you about 20 things that are good to know when you’re about to start, or have just started, your web development career. This will help you manage expectations and set you on the right path.
1. You don’t need a degree to program
To start programming you don’t need a degree. Most things can be found on the internet, especially the basics. You can teach yourself how to program all by yourself, with some help from the internet.
2. Googling is a skill
Since you just started web development, you don’t have all the knowledge that’s required to solve certain problems yet. This is totally fine, and it doesn’t mean that you can’t solve these problems. Knowing how and what to google is a serious skill that can save you a lot of time.
3. You can’t learn everything
There is so much to learn. Just take a look at all the different popular JavaScript frameworks that exist: React, Vue, and Angular. You can’t learn them all. And there is probably no need to learn them all, either. Just focus on the JavaScript framework that you like the most or your company works with.
4. Writing easy code is the hardest thing to do
Most relatively unexperienced developers write fancy code. This is a way of showing off and letting other developers know how well they can code. This is not what you should do. Keep your code as simple as possible.
5. There’s no time for proper testing
From my experience, developers are kind of lazy when it comes to testing their work. Most developers will agree that testing is not the most fun part of their job. In the end, you’re a developer who tries to make stuff, not break it.

And then we have deadlines. Most of the time, you have to deal with a deadline. Once there’s the slightest idea of missing the deadline, one of the first things that get sacrificed is testing. This really happens, even though everybody agrees that it’s not good for the end result.
6. Time estimations are never even close
It doesn’t matter if you are estimating a feature in hours or giving points to a user story during the refinement. Estimations in software development are never even close! There’s always going to be this one little feature that you think you can build in one hour. Once you’ve opened the code, you realize that you have to restructure a big part of the application to get this little feature to work. Well, so much for that time estimation.
7. You’ll feel ashamed when you look back at your old code
When you are just starting out as a developer, you just really want to fix things. If the code works, it’s fine. To inexperienced developers, working software and good software are considered the same. But as you grow as a developer, you will eventually look at some old piece of code and think, Did I really write this spaghetti code? Well, there is really just one thing that you can do in this type of situation: Have a good laugh about it and clean up the mess that you made earlier.
8. You’ll spend way too much time looking at bugs
Debugging your code is a big part of your job. Writing bug-free code is impossible, especially when you’re not that experienced. The thing that makes debugging time-consuming for inexperienced developers is that they don’t know where to look. And sometimes they don’t even know what to look for. The worst part is that a lot of the time, you’ve created these bugs yourself.
9. Internet Explorer is the worst browser that was ever created
Internet Explorer, also referred to as Internet Exploder, will make you feel bad about all the CSS that you’ve written. Even the most basic styling will break in Internet Explorer. At some point, you will ask yourself why there are so many different browsers. Most companies will work around this problem by only supporting Internet Explorer 11 and newer, which helps.
10. Work stops when servers are down
Eventually, the development server or version control server will go down. If you’re not working on your local machine, this means that you can’t do anything. And there is nothing you can do about it. Well, time for a coffee break, I guess.
11. You’ll pretend that you understood everything your colleague said
You will at least once have a conversation with another developer who is super-excited about a new technique or tool. You end up agreeing to most of what the other person said. But the truth is that you didn’t understand most of that conversation.
12. You don’t need to memorize everything
Programming is all about applying knowledge. There is no need to memorize everything. You can always look for a resource on the internet. You just have to know where to find the right resource. Memorization will come while you work on projects and once you get more experienced.
13. You need to be a good problem solver
And on top of that, you need to be creative. Programming is all about solving problems. The same problem can be solved in multiple ways. Creativity comes into play to solve problems in an easy and effective way.
14. You will be reading a lot
A lot of your time will be spent reading. Reading about new techniques, best practices, tooling, and staying up to date with things that happen in the industry. And let’s not forget about books. Reading is a great way to expand your knowledge and stay up to date.
15. Responsive can be a pain
Trying to get your website to look awesome on all devices can be a real pain. Since there are so many different devices and browsers, there is always a combination of a browser and device that doesn’t look great.
16. Knowing how to debug saves lots of time
Debugging can be very time-consuming, especially when you don’t know where to look or what to look for. Having a good understanding of how your code works and mastering the tools to debug will save you a lot of time. A good way to improve your debugging skills is to learn how the developer tools in your browser work.
17. You’ll be looking at suggested solutions that won’t work for your problem
When you run into a problem that you don’t know how to solve, you will probably google for an answer. Most of the time, you’ll find suggested solutions on forums, like StackOverflow, that will give you a good push in the right direction. But also most of the time, the suggested solution can’t be simply copied and pasted to solve your problem. This where your problem-solving skills and creativity are needed.
18. A good IDE will make your life much easier
Before you start typing any code you should spend a little bit of time on searching a good IDE. There are a lot of good IDEs, both free and paid, out there, which will make your life as a developer a lot easier. IDEs can help you out with syntax highlighting and showing syntax errors. Most IDEs support plugins that allow you to customize your IDE.
19. Working with the terminal can make you more efficient
If you are used to using a Graphical User Interface (GUI), working with the terminal might seem kind of intimidating at first. But knowing your way around the terminal can make you more efficient. The terminal is a very powerful tool that makes it possible to complete tasks much more quickly than you could with graphical tools. Working with the terminal is something that you should really want to learn and get comfortable with.
20. Don’t reinvent the wheel
When you want to build some standard feature, you should really check GitHub to make sure you’re not reinventing the wheel. There is probably already a popular and stable library for the feature that you’re looking to recreate. Look for active projects that have good documentation. If you want to add additional features or rewrite some feature, you could always create a merge request or fork the project.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第515期：《表情无处不在 gitmoji》

12 8 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《表情无处不在 gitmoji》
今日推荐英文原文：《The most important skill a programmer can learn》

今日推荐开源项目：《表情无处不在 gitmoji》传送门：GitHub链接
推荐理由：有的时候一个表情可以有很多含义，所以用起来很管用。这个项目能为 Git 中的提交信息添加表情符号，看多了文字突然冒出来一个表情自然会相当显眼，在团队中为一些通用的操作统一添加表情符号也能更好的辨别提交信息，在这层意义上它能够最大限度的发挥将人们的目光聚集在自己身上的功能。
今日推荐英文原文：《The most important skill a programmer can learn》作者：Huseyin Polat Yuruk
原文链接：https://medium.com/free-code-camp/the-most-important-skill-a-programmer-can-learn-9d410c786baf
推荐理由：不要只管写什么而不管该写什么啊kora！
The most important skill a programmer can learn
No, no, no, no, and no. And no.

A big NO. Clear as that.

All you have to do is to bring those two letters together and say the word.

Now, let’s say it together. NOOOOOOO!

Good start.

But wait a minute. Say NO to what and when?

Well, this is the important point where most of the programmers (even seniors) get easily confused.

As a programmer, writing code is the biggest part of your job. In your programming lifetime, you will have to deal with different kinds of code requests. Each request will force you to make difficult decisions. That all is OKAY. Nothing wrong with that. This is what everyone expects from you, as a programmer: Writing code. However, here is a question: Should you write all the code that is requested from you?

This question brings us to the most important skill a programmer can learn:
Knowing when not to code is possibly the most important skill a programmer can learn. — The Art Of Readable Code
I couldn’t agree more. Why is that?

Programming is the art of solving a problem. So naturally, programmers are problem solvers. As programmers, when we have a new problem in front of us ready to be solved or any other reason that needs from us to write code lines, we get excited.

And that is okay because we are programmers. We love writing code.

However, getting too excited about writing code makes us blind. It causes us to ignore some important facts that can cause bigger problems we will have to deal with in the future.

So, what are those important facts that we tend to ignore?

Every line of code you write is:
- code that has to be read and understood by other programmers
- code that has to be tested and debugged
- code that will increase defects in your software
- code that probably will introduce new bugs in the future
As Rich Skrenta wrote, code is our enemy:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean the old code has to be adapted.

The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.

Code is produced by engineers. To make more code requires more engineers. Engineers have n² communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

It’s so true, isn’t it? The programmers who inspire you with their productivity and coding mentality are those who know when to say no and when not to code. The software that is easy to maintain, that lasts long and keeps helping their users is the one that doesn’t contain any unnecessary code lines.
The best code is no code at all, and the most effective programmer is the one who knows when not to code.

How can you know when not to code?
It’s natural to get excited when you’re working on a project and think about all the cool features you’d love to implement. But programmers tend to overestimate how many features their project needs. Many features go unfinished or unused or simply make the application overcomplicated. You should know what is essential for your project to avoid making this mistake.
Understanding the purpose of your software and its core definition is the first step to know when not to code.
Let me give you an example. Let’s say you have software that has only one purpose: managing emails. And for that purpose, sending and receiving emails are two essential features to your project. You can’t expect that software to manage your to-do list as well, can you?

So you should say NO to any possible feature requests that are irrelevant to this definition. This is the moment you can be exactly sure that you know when not to write code.
Never expand your software’s purpose.
Once you know what is essential for your project, you will be conscious next time when you evaluate possible code requests. You will exactly know your requirements to write code. Which feature should be implemented? Which code is worth to write? You will question everything because you will know exactly how unnecessary code can kill your project.
Knowing when not to code keeps your codebase small.

The Art Of Readable Code

There are only two or three source files when you start your project. All looks so simple. It takes just a few seconds to compile and run the code. You know where to find exactly what you’re looking for.

Then, as the project grows, more and more source files fill your directory. Each code file contains hundreds of code lines. To organize them all, you will need multiple directories soon. Remembering which functions call other functions is more difficult, and tracking bugs requires a bit more work. Managing your project becomes difficult, and you need more programmers to help. Communication overheads increase as the number of programmers increases. You get slower and slower.

In the end, the project becomes huge. Adding new features is painful. Even making small changes takes hours. Fixing present bugs always introduces new bugs. You start missing deadlines.

Now, life is a struggle for you. Why?

Because you didn’t know when not to code, you said YES to every possible feature request. You were blind. Coding something new caused you to ignore essential facts.

It’s like a horror movie, right?

This is what will happen if you keep saying YES to everything. Know exactly when not to code. Eliminate all unnecessary code from your project. This will make your life easier and make your software last longer.
One of my most productive days was throwing away 1000 lines of code. — Ken Thompson
I know that knowing when not to code is so hard. Even for senior programmers. Perhaps what I wrote in this article is hard to understand for junior programmers, and that is okay and understandable.

I know you have just started your programming journey and you want to write code. You are so excited about that. This is good. Never lose this excitement but also never ignore the important facts. We learned them by making our own mistakes. You will make mistakes as well, and you will learn from them as well. But at least you can be more conscious if you can learn from our experience.
Keep coding but know when to say no to coding.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第514期：《黑夜给了我黑色的屏幕 darkreader》

11 8 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《黑夜给了我黑色的屏幕 darkreader》
今日推荐英文原文：《You need juniors in your team》

今日推荐开源项目：《黑夜给了我黑色的屏幕 darkreader》传送门：GitHub链接
推荐理由：不管是因为大晚上被某人叫起来赶工，还是因为舍友都懒得开灯，在黑暗中使用电脑几乎是家常便饭。这个 Chrome 的插件可以提供黑暗模式来方便阅读，同时减少眼睛的疲劳程度。爱护眼睛可是很重要的，毕竟不是每个人天生都会不近视，留得青山在，不愁没柴烧，身体可是爆肝的本钱不是吗？
今日推荐英文原文：《You need juniors in your team》作者：Mirek Stanek
原文链接：https://medium.com/@froger_mcs/you-need-juniors-in-your-team-ef815fb2c175
推荐理由：初心者有初心者才能做到的事情，熟练工有熟练工才能做到的事情（但是这不是停留在初心者的理由）
You need juniors in your team

Don’t underestimate less-experienced software engineers
Business is going well, and your engineering team is not a one-person army anymore. Instead, you have a couple of mid- or senior level devs on board. Now you need to grow a team to make your product even better. There is no better time to start hiring some less-experienced people.

This, of course, doesn’t always have to be true. Juniors probably won’t help you much if you are in the first phase of building rocket ships or quantum mechanics algorithms to solve NP-complete problem. But the truth is that the majority of tech products are built on top of existing solutions, SDKs/libraries, APIs, or managed cloud platforms. And this is the perfect space for a dream-team of junior and senior software engineers collaborating.

Hiring juniors is a great strategic move — it doesn’t have anything with your budget, but with keeping your tech stack and engineering team a top-class.

What does it mean?
Bulletproofing your tech stack
There is a great book called “Antifragile” by Nassim Nicholas Taleb that starts with the prologue:
“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. According to Taleb, the opposite of fragile is antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.”
Is your platform antifragile? When less skilled engineers can blow it up with their rookie mistakes, you shouldn’t blame them. Maybe It’s because your QA process or deployment automation isn’t good enough to catch those things early. If you cannot hire junior software engineers because your system doesn’t tolerate any mistakes, that’s very bad. Are you sure that your seniors spend their time effectively — by delivering new value to the business, instead of fighting with fire or testing things manually?

Automate processes, hire juniors, and challenge the engineering team giving beginners more responsibilities. By breaking things early, they will help you to make your tech stack antifragile.
Decreasing the entry-level of your technology
At some point in a software engineering career, new language, another system or cloud platform become just tools. They all look and work very similarly. And your coding wizards will try them on every possible occasion — to learn something new or challenge themselves. Their senior teammates won’t mind that — It’s a piece of cake for everyone to understand everything (this is how we, devs flex our ? muscles).

But there are not so many seniors on the market. Soon or later, you will need to scale up the team. You will need to hire people who are just okay. They do code in one language, and know one cloud platform — they have a great life beyond coding.

Now, how much time is needed for new-joiners until they will start contributing into your 10-different-languages tech stack? Is it one week or two months? Having juniors on board early days will make your seniors simplifying things. If their solutions aren’t easy to understand, they will need to spend their precious time, explaining them to less experienced teammates.
Let your seniors do the senior job
It’s also worth defining the expectations for each of the positions. In simplified terms — junior software engineer builds features with support and advisory, mid-level is independent with a delivery, and senior should scale things up. What does it mean exactly?

Scaling can be done with thoughtful and accurate decisions about code architecture, used platforms, etc. But scaling is also tightly connected with a proper knowledge transfer. It’s about making sure that senior inspires and leads less-skilled engineers so they can build things most efficiently. Seniors shouldn’t be just great coders. They should be effective problem solvers, where very often working with people is more important than working with code. Working with juniors is a great soft skills training.
Keep software engineering levels ladder healthy
What does it mean to be a senior or mid-level engineer in your company? If only seniors can deploy to production or add a new module to a mobile app, it seems that your expectations regarding this position aren’t very high. How then you name people who know and do more than that?

By hiring juniors, you have a great chance to diversify your expectations. Let juniors do new modules or push code to production. Make sure that full ownership over product feature is one of their goals. Does it look unrealistic at the moment? That’s even better! Train juniors to achieve their goals, and work with seniors to simplify tech stack, so impossible becomes simple.
You need no heroes
In the early days of product existence, every week is full of heroic acts. Your code magicians fix things in the middle of the night, work 12 hours per day, and answer phone calls 24/7. They need to deliver ASAP. But at some point, fast delivery becomes equally important to stabilization. And later, they both are replaced by a new requirement — scalability. When you have to handle user base growth and scale the engineering team at the same time, there is no more space for heroes. You should start thinking proactively, not just fighting with fire all the time. The company cannot hold breath whenever you deploy things on production. You cannot spend half a year looking for coding rockstars who will spend another month or two in your on-boarding process.

You need juniors, well-motivated, hungry for knowledge, ready for challenges that very often relieve your tired heroes. They will make your team healthy and antifragile. You will find and hire them in weeks.

If you can onboard them in days, you are already there. If not, work hard to make it happen. It will pay off surely.

This blog post was written base on my experience in working with people on different levels in their career ladder. A couple of years ago it was only senior software engineers who could publish apps on App Store or Play Store. Only the most skilled people could build new product features independently.

Today, one of our KPI says — “1-week onboarding for an intern” (our new-joiners pushed code to production within the first four days). Our deployment is fully automated, so it is expected from juniors to take release captain role in turns with any other engineer. The same with product features delivery — becoming a mid-level software engineer to have ownership of features is too late for us. All of those aren’t just because we have high expectations for software engineers. It’s because thanks to feedback from juniors, we could simplify processes and decrease the entry-level for our tech stack.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第513期：《热点 TopList》

10 8 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《热点 TopList》
今日推荐英文原文：《Blog Posts and Programming: 7 Reasons to Write》

今日推荐开源项目：《热点 TopList》传送门：GitHub链接
推荐理由：这个项目可以获取各大热门网站的热门头条，从而让你知道大家的关注点都放在哪，用来扫一眼了解一下最近发生了什么也是不错的选择。当然了，如果想要了解自己需要的一些新闻或者事件的话，自己去找找各种资料才是最好的选择，毕竟无数事实告诉我们人类可是很容易被没有证据的谣言牵着鼻子走的。
今日推荐英文原文：《《Blog Posts and Programming: 7 Reasons to Write》》作者：Matt Cummings
原文链接：https://medium.com/better-programming/blog-posts-and-programming-7-reasons-to-write-e502350ff51a
推荐理由：写技术博客的好处——兴许你会解决一个别人正在解决的问题
Blog Posts and Programming: 7 Reasons to Write

What can writing tech-related articles do for your career?

Photo by Glenn Carstens-Peters on Unsplash

When I first started my journey at Flatiron School, I was informed that we were responsible for writing five blog posts about various aspects of coding, ranging from trends in the market to things like breaking down ORM and Ruby. I actually enjoy writing, so I didn’t mind it too much. For some, however, it can feel like extra weight to a program that already has a lot of bulk. In this post, I want to explore why posts like this can have several benefits and are very much what you make of them.

This may seem more of a fluff piece to some. With that in mind, I will say that if I didn’t believe in what I wrote, then I simply wouldn’t write it. The goal of this article is to bring some introspection to why writing posts about programming can be helpful, not only to students in the same boat, but also to technical writers as a whole. Without further ado, let’s begin!
1. Writing a Post Can Be Lucrative

Photo by Alexander Mils on Unsplash

First and foremost, this is probably going to be the most-viewed section of this article. It’s eye-grabbing and piques interest. If your articles follow suit and are written well, they can make money for you on sites like Medium. I’ve made a little less than ten dollars so far, so, while it’s not something that’s going to bring in the bills right away, it gives you some spare income for something you might end up having to do anyway.

As you gain notoriety in your posts, you increase the chance of earning more cash. It’s uncommon, though not unheard of, for some authors to make 500 dollars from their posts in a month on Medium. While you may not make as much as that, I think we can all agree that any extra money helps. So why not write something worth it?
2. Writing a Post Can Be a Resume Builder

Photo by Helloquence on Unsplash

When you’re entering the job market and fresh out of a boot camp or other form of educational institution, your portfolio is probably going to be the most important thing employers will be looking at. However, you can view blog posts as a sort of “spice” to that — if you have a lot of well-written articles, they’re only going to work in your favor.

This relates more to posts whose content is more technical in scope, but any thought-provoking article about the industry is sure to garner interest. Blog posts can be supplementary — for instance, I am in the middle of writing a series about regular expressions. I consider myself moderately skilled in their usage, but I don’t have anything particular in my portfolio at the moment that proves that. With my posts about this topic, although they don’t delve too deep into the logic, I have conveyed that I know how they work and how to apply that logic in different situations.

It’s a great way for potential employers to not only see additional knowledge that might not be explicitly on your skill list but also to see how you structure professional documents, which can be reflective of your organization as a whole.
3. Writing a Post Can Get You Published

A collage of tech publications on Medium by Matt Cummings

This ties into the above two sections. I got incredibly lucky with my first post and was approached by someone at the publication Better Programming who asked to include it in their publication. Not only does this look great on a resume, but it also raises the chance of readers seeing your posts and making you some cash. More importantly, publishing can lead to new connections, establishing new friendships and opportunities you may otherwise not have come across.
4. Writing a Post Can Prompt You to Explore a Topic

Photo by Jon Ly on Unsplash

A popular saying is that if you can explain a topic well in a way that makes sense, then you know a lot about said topic. I find that really true — in fact, note-taking can be seen as a supplement of this. Extending this logic to your posts gives you an insight into how much you actually know about a subject and how you convey your knowledge in the subject to an outside source. Being able to explain your thought process to others is a great communication skill, something touched upon more in the following section.
5. Writing a Post Improves Your Linguistic Skills

Photo by Benny Kirubakaran on Unsplash

I think one of the best things a person can do for themselves is to learn a new skill. Writing is one of those easy-to-learn, hard-to-master sorts of talents, but doesn’t require that many resources for you to improve in it. If you have any sort of device used for word processing, whether it be a pen, phone, or computer like the one I’m typing on right now, then you have the opportunity to work on your writing style and hone it.

One of the best things about literature is that many authors have a distinct flair, imparted by not only their sentence structure but also their word choice. Word choice can completely change the tone of an article from bland and boring to thought-provoking and one that heightens the interest of readers on the topic. By writing successive articles — which really, is akin to practicing any other skill, such as playing the piano — you will learn more about the way you want to write, about what works, what doesn’t, and what can be improved.

I’d like to think that I come off sounding intelligent in what I author. A lot of that is due to my previous experience in writing, but also to the use of Google and thesauruses to find the exact word I need to get my point across. If you get published, it’s interesting to see how the editor refactors your post, to see what changes they make. While you may not agree with all the changes, it provides you with valuable feedback into how you structured everything and the linguistic decisions you made.

Writing articles about coding can come off as dry and cryptic, especially if you’re just entering the world of it. It’s your job as an author to make that post interesting and understandable to an audience. By practicing this skill, you will obviously get better at technical writing, but also at writing as a whole. This is an extremely valuable skill in any workplace environment — anyone who can communicate effectively and explicitly on a topic is sure to be the go-to person for assignments pertaining to that topic.
6. Writing a Post May Spark a New Interest

Photo by Eric Han on Unsplash

While it’s very hard to think of content to write about in the beginning of your journey as a technical writer, you’ll undoubtedly come across some topic that at least mildly interests you (otherwise, why the heck are you writing about it?). It doesn’t even have to be something super specific. It could be about the organization of code, or what you feel is an unexplored topic (which is why I wrote about regex in the first place). From there, you may find that your interest in that topic increases or possibly discover a related field that you want to learn about.

Teaching yourself new things about that topic will give you two benefits: something to write, and an increased understanding and proficiency in that skill, further differentiating you from other people in this field. Having something unique on your resume can make you more marketable. It’s very possible some employers will gravitate more towards with you if one of your interests heavily aligns with that company’s goals or business strategy.
7. Writing Your Post Helps Someone Else

Photo by Mimi Thian on Unsplash

This should be obvious, and while it may not affect you directly like the other sections I’ve written here, it’s a fact nonetheless. I have run into some posts on here that really helped put something in perspective, and I’m thankful for the person who wrote that content. I’m not going to give you some feel-good, after-school-special sort of nonsense. The main reason you’re writing these posts in the first place is to either explain a concept to readers, to elaborate on an already established topic, or to give an opinion about something. Therefore, what you write can have an effect on readers. Since you’re already at the keyboard, why not make whatever you’re working on the most beneficial thing it can be?

One of the main reasons my posts are so thorough is so that readers can understand — in plain English — what the hell I’m talking about and how they can use what I’ve written to create code of their own. One of my largest frustrations is that when I’m looking for information on how a certain piece of code works, I find many explanations become so convoluted and distorted that it feels as if I’m traversing a black hole. You get foreign segments of code that you’ve never seen before that aren’t even elaborated upon or some kind of nonfunctioning metaphor that just takes up space on the page and does nothing to actually elucidate whatever the person is trying to say.

I absolutely hate running into that and the time wasted in looking for something well written that actually makes sense. My goal in any post I author is to make the point as clear as humanly possible. It’s why many of them are really procedural in structure and almost overly detailed at points.

To prevent yourself from rambling and to get back to the point, one of the most important things you need to consider when writing a post is that other people are going to read it. Keep that in mind, and you’ll find yourself making sure that what you’ve written is organized, understandable, and a useful piece of information. That will only make it better for those who consume it.
Conclusion
As I stated in the introduction, the objective of this post is to make us, as authors, think about why we’re writing these posts in the first place and how they can benefit us and the readers who take them in.

All seven reasons are points you can refer to during your writing process, whether it be from buzzwords you think will improve the popularity of your post to your choice of words in a sentence. I implore all of you — even if you don’t think you have the talent, because it will come — to keep writing about topics you’re passionate about, staying cognizant of what I’ve gone over here. If you keep at it, the quality of your writing will escalate ever higher. That’s a benefit for everyone, authors and readers alike.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/