开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《仅仅一瞬间 trace.moe》
今日推荐英文原文：《25 Lessons I’ve Learned as a Developer》
今日推荐开源项目：《仅仅一瞬间 trace.moe》传送门：GitHub链接
推荐理由：兴许在不少时候，最开始接触某部动漫的契机就是见到了某个名场面的截图。这个项目就能解决只知道图片不知道来源的尴尬问题，只要输入一个图片，它就能返回给你图片的出处，出现的具体的章节和时间点，以及这部动漫的具体资料，从此不再需要问你那见多识广的朋友们“这是啥番啊？”的问题了。
今日推荐英文原文：《25 Lessons I’ve Learned as a Developer》作者：Aphinya Dechalert
原文链接：https://medium.com/better-programming/25-lessons-based-on-my-experiences-as-a-developer-61644418a3ed
推荐理由：作者在开发者的路上学到的经验教训

25 Lessons I’ve Learned as a Developer

Being perpetually curious, coding to the conditions, bigheadedness, and more

I actually started coding a long time before I got my first job as a developer, booting up websites here and there for friends, and friends of friends. I grew up in the days of dial-up Internet, floppy disks, and cassette tapes — the classic 90s kid with the Fresh Prince of Bel-Air theme song playing around dinner time.

My first real job as a developer was somewhat accidental. I was hired to play the new marketing girl but ended up refactoring the entire mobile application front-end within six months of getting the job.

It was a weird jump and a massive learning curve. It was my tinkering days that got me through the door.

As we pass the midway mark and make our way through the second half of the year, I’ve been reflecting and thinking about my journey so far as a developer.

Here are 25 lessons based on my experiences and what I’ve learned from my journey thus far.

Lessons I’ve Learned as a Developer

  1. Everyone is essentially self-taught in the industry. Tech generally moves too fast for traditional educational institutions to catch up. If you want to boot up something quick, you’re better off doing micro and nano degrees and certifications rather than sitting through three years of exams.
  2. Traditional education still has a place in foundation studies. A bachelor’s degree is one way to get your foot through the door but it isn’t the only way. If your brain is more practical than theoretical, and you can’t fund student loan repayments for the next 10 years, the Internet has a lot more guides and structures available now than it did 10 years ago.
  3. To make it in the industry, you have to be perpetually curious. You’re constantly asking questions about how things work, why things work — especially in eureka moments when everything finally falls into place.
  4. For a long time, you’ll feel like you’re not really improving — until you look back at your old code or have to explain something to someone.
  5. The amount of code you create matters as a junior. Learning to code is like learning to write. The more you write, the more you’ll start to notice patterns, inefficiencies, and how to fix them.
  6. As a junior, you’ll hit a stage of bigheadedness and think you know everything. As an intermediate, you’ll find yourself deflating egos that you once exhibited. As a senior, you’ll give just enough guidance to steer your less-experienced peers in the right direction, but you’ll also let them struggle just a little bit because it’s all part of the learning-to-create process.
  7. Bugs occur because there is a gap in knowledge. Code is an act of translating requirements for the compiler to transform into ‘computer speak’. When things go wrong, it’s because there’s been a blip in the translation by the developer.
  8. When people tell you that you’re doing agile but don’t let you in on the planning phase that directly impacts you, it’s not real agile.
  9. As a developer, you’ll be in a constant state of knowing but not knowing at the same time.
  10. Formatting is the deal-breaker when it comes to readability.
  11. Code is a communication tool. Write it in a way that is human-readable and not littered with secret code names that only the initiated will understand. When that happens, the code is incapable of being self-documenting and concise.
  12. Functional programming patterns have their place in making things less complicated. Object-oriented patterns also have their place as an organization and categorization tool. These two patterns are not mutually exclusive from one another and co-exist if necessary.
  13. Code to the conditions. Over-abstraction for the purpose of ‘best practice’ can lead to more technical debt in the long run.
  14. All software ages. ‘Perfect’ code five months ago has the potential to be inefficient code due to changes in requirements, dependency upgrades, and unaccounted-for bugs and blips in logic.
  15. Your database is everything. If it’s over-engineered, chances are that your back end will also be convoluted as a side effect.
  16. When working in teams, a flat and automated process will be the deal-breaker for your productivity. A flat structure means you can move code through the pipeline faster, and automated means less time clicking, typing, and waiting for things to get done.
  17. Inheriting bad code is a rite of passage. Everyone goes through it at some point in their careers. It is also an opportunity to learn from the mistakes of others, and space to do good things for the future direction of the software.
  18. You’ll constantly be cleaning after others and your past creations. This is because code is like food — if it’s not actively consumed, it becomes legacy and can turn bad with age.
  19. Work-life balance is still relevant for developers because we’re all still humans. Don’t be the stereotype and neglect yourself, your friends, or your family. Take care of yourself and don’t let the code life take you over.
  20. If you feel like you’re on the brink of a burnout — stop. Take a break and then come back — but to code that has a higher purpose or personal meaning to you. Software is the interface between the customer and the business. As developers, we act as the force that allows this to happen. It’s alright to jump ship if you feel like you’re not really contributing to this — or you simply don’t believe in it. You need to be proud of what you’re making. Regardless of where you end up, you’ll still make a decent income.
  21. Don’t get too hung up on other people’s code. Work with what you’ve got. Focus on improving yourself to become the benchmark.
  22. If no one is calling you in for an interview, get creating. If you’ve got no experience to put down for your resume, get creating. If you’ve got a spare weekend and have an idea, get creating. As developers, we are in the business of creating code. The moment we stop is the day we risk becoming part of the management team.
  23. Don’t just learn to code. The bigger your domain of knowledge, the easier it will be to code your projects. This is because coding is transforming the world, its rules, and processes into a digital representation of reality. You can’t effectively create something you don’t understand.
  24. You will never know everything there is to know about code — but ideas are finite. It’s better to have a large repertoire of ideas and use them as the guideline for your code creation process. You’ll end up with sturdier software.
  25. Software books are still worth reading and investing in. That’s where a lot of the big ideas are explored in depth — especially those by Robert C. Martin and Martin Fowler. They are the industry gods among us mere mortals.

Conclusion

The journey that’s lead me to where I am right now as a developer has been peppered with good and bad code, interesting solutions, and not so great architectures.

As I move into flying solo and doing more freelancing and contract work, my experiences as a developer will certainly grow and move in a different trajectory.

But for now, this is it and until next time — thank you for reading.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/