今日推薦開源項目：《命令行遊戲 wolfentext3d》
今日推薦英文原文：《The Toils of Software Development》
今日推薦開源項目：《命令行遊戲 wolfentext3d》傳送門：GitHub鏈接
推薦理由：圖形學裡早就講過圖像是由像素堆起來的，那麼命令行里自然也有辦法實現圖像。這個項目用 Ruby 在命令行里不僅畫出了圖像，還做出了有模有樣的 3D 遊戲，當然了這些像素都是用符號一個個堆起來的，看起來相當的晃眼……但是儘管形不似，神似還是成功的做到了。
今日推薦英文原文：《The Toils of Software Development》作者：Bob Roebling
原文鏈接：https://medium.com/better-programming/the-toils-of-software-development-23b8989e70f4
推薦理由：來看看軟體開發的另一面
The Toils of Software Development
Hi, I』m Bob, and I write bad code
At different points in your software development career, you will experience at least one, if not all, of the problems listed here. My goal is to inform you of things that could discourage you from becoming a developer, before you reach them. This will prepare you to handle them, using a plan you』ve devised with a clear mind. Why? Because development is hard and it will take persistence to get better.Failure
The first truth of programming is that you will fail. I do all the time. The compiler (or interpreter) is good at reminding me of my failure rate. What it is not so good at is telling me 「Good job!」 when I fix those pesky bugs — I have to do that myself. Learn to appreciate the failures, small and large. Look at failed compiles and program crashes as learning experiences that make you better at what you do. If you want to be the sharpest tool in the shed, you have to find and remove the burrs!Impatience
You will lose patience at some point. This is especially likely when you hit a tedious part of the code. The first time I realized this was when I tried building a prestige tracker for a well known first-person shooter. After entering several level point requirements by hand, I got frustrated because writing the software was slow and tedious. Later I would take this impatience and use it to my benefit by finding better ways to do things (e.g. parsing JSON from Web APIs). While it』s great using a wheel someone else built, sometimes you have to do the tedious part yourself. Be sure that when you do, you write it in a way that』s reusable. Your future self will thank you.
Photo by Christian Erfurt on Unsplash
Fatigue
Mental fatigue is my worst enemy, probably more than any other toil of development. When you face fatigue, it』s hard to get started on new projects or complete existing projects because of the technical debt you』ve created for yourself that you now need to fix. This kind of fatigue also comes about from working on many different projects, working in many different languages on the same project, or just working on a project in a language you don』t know. You overwork your thinking cap, and development slows to almost a grinding halt. The best way to take care of fatigue is to do something else not related to development, better yet, computers period. Go outside and walk around the building for 15 minutes with someone else. It helps keep you distracted for a while and, if they are a developer, you can bounce ideas off of each other about how to solve an issue one of you might have. When I』m at home, I might fire up a game I don』t have to think too hard about and play for about 30 minutes.Imposter Syndrome
Imposter syndrome is a mental game that comes around when you get your first job as a developer. Most of the time, when we think of developers, we think of the computer scientists (Turing, Richie, Torvalds, Gates, Wozniak) who have had tremendous accomplishments. Because of this, we can feel like we don』t belong with the rest of the developers. The best solution for this is to learn something new every day. If something seems complex, there』s a good chance you』re missing the required information — a pre-requisite topic. After a while, things will start making sense and you will go from feeling like an imposter to feeling like a developer. It』s vital that during this stage, you take yourself too seriously. Don』t let others get to you and take all criticism as an opportunity for improvement.
Photo by Lysander Yuen on Unsplash
Analysis Paralysis
Analysis paralysis is fun to say but it can be a real pain. Have you ever refactored your code before you even committed it to a branch? What about refactoring your code before you write it? This in itself is normal, but have you ever spent more than a workday doing this? If so, you may have experienced analysis paralysis. There』s only one way to get past this: Get it working, even if it is missing features or may not work as efficiently as you』d hoped. Make all of those thoughts tomorrow』s food and move forward with what you have.Educational Boundaries
A manager and friend once told me that they had an employee once who, no matter how many times they were taught something, never could quite figure it out. He said that they had reached their aptitude. I think this is partially true and is qualified by not fully understanding the prerequisite knowledge required for a task. Programming never came easy to me. But with perseverance, I was able to break through what I thought were aptitude caps by learning other things. If you』ve gone far enough in your education to run into some of these other issues, an aptitude cap is not your problem. If you run into any of these issues, remember you』re not the only one to fall into these traps and there』s always a way out. Good luck!下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
