Daily Productive Sharing 244 - How to Start as A Better Developer?

Dr Selfie -

One helpful tip per day:)

(The English version follows)

#work #finance

已经工作多年的你会有哪些建议给刚开始工作的自己呢？Gergely Orosz 列出了七条建议给刚开始写代码的自己：

  1. 每年细读一到两本软件开发的书籍；
  2. 深入学习你所使用的语言；
  3. 经常和其他程序员一起写代码；
  4. 写单元测试；
  5. 经常重构代码，并学会使用重构工具；
  6. 好的工程实践是基于经验的，积累这些经验；
  7. 以教促学 Daily Productive Sharing 205 - 20210528

你会给刚开始工作的自己哪些经验呢？欢迎分享给我们:)

如果你觉得今天分享有帮助，不妨把它分享给你的朋友

原链

Advice to Myself When Starting Out as a Software Developer

需要更棒的简历，不妨试试我们的 CV Consultation

如果你也想成为更高效的人，欢迎加入我们的 TG group

Gergely Orosz lists seven tips for those just starting to write code:

  1. Take the time to read two books per year on software engineering
  2. Learn the language you use at work in-depth, to the very bottom
  3. Pair with other developers more often
  4. Write unit tests and run them against a CI
  5. Make refactoring a habit and master refactoring tools
  6. Know that good software engineering is experience. Get lots of it.
  7. Teach what you learn Daily Productive Sharing 205 - 20210528

What suggestions would you give to yourself when you are just starting out? Feel free to share them with us :)

If you find today's sharing helpful, why not share it with your friends?

Advice to Myself When Starting Out as a Software Developer

Need a superb CV, please try our CV Consultation

Excerpt

By properly reading, I mean taking notes, talking chapters through with others, doodle diagrams, trying out, going back, and re-reading.
When I read, I don't do it quickly. In fact, I do it rather slowly. I usually go a chapter or two in one sitting.
Books are in-depth, and well-organized knowledge.
Don't be ambitious: one book every six months is already great. Pick a book, and spend the time to properly read it.
Learning the language I used at work in-depth was one of the best decisions I made.
The more languages you know, the more you can evaluate their strengths and weaknesses.
And the more languages you know, the easier it is to pick up new ones - and go deep easier, when you need to do so.
I ended up learning a lot - while also telling them I didn't think their comments were fair. They took note and suggested I pair every time I feel this is the case.
The developer challenged us that given the test coverage, it should be a piece of cake. If the tests pass, it works. I was skeptical. But that's exactly how it worked.
This was when I realized the safety net that a strong test suite gives and how it allows refactoring without fear.
I realized I was afraid of refactoring as I missed both the practice and the tools to do this well.
The best software engineers have a mix of learned knowledge and real-world experience. The knowledge you can learn. The experience, you need to go after.
Look for opportunities to work on different stacks, different domains, and challenging projects.
The best way to learn something is to teach it.
These days, when I want to learn something well, I sign up to do a public talk about it.
By the talk, I had no choice but learn all the details. And I had plenty of pressure to do so: about a hundred local developers signed up for that event.
The nice thing about teaching others is you can only win. Not only will you learn something by teaching, but you'll also help and inspire others.