Communities and Collections
Posts
Post has attachment
Post has attachment
F.I.R.S.T Principles of Unit Testing
Fast: A developer should not hesitate to run the tests as they are slow.
Repeatable: Deterministic results - should yield the same results every time and at every location where they run.
Self-Validating: No manual inspection required to check whether the test has passed or failed.
Thorough: Should cover every use case scenario and NOT just aim for 100% coverage.
Fast: A developer should not hesitate to run the tests as they are slow.
Repeatable: Deterministic results - should yield the same results every time and at every location where they run.
Self-Validating: No manual inspection required to check whether the test has passed or failed.
Thorough: Should cover every use case scenario and NOT just aim for 100% coverage.
Add a comment...
Post has attachment
Unit Tests always give the same consistent result when executing anywhere (DEV/QA/Prod servers), anytime (next day, next month, next year, next 5 years).
Add a comment...
Post has attachment
Empathy is helpful for being a team member and a mentor. Put yourself in your manager or another developer's shoes. Why are they making their decisions? What can you do to help them? Having empathy will definitely improve your ability to be an effective teammate. If you're an employer, you can retain your employees for longer, and they will be more effective workers if you display empathy
You can learn so much from other programmers -- one person cannot know everything or anything close to it in the world of code. Be receptive to constructive criticism instead of defensive. You can improve your code and yourself from feedback, and being stuck in your ways doesn't lead to growth. You aren't always right, and you should be receptive to other people's ideas.
The first person that you need to have patience with when you are programming is yourself. Programming is hard and sometimes you will have bugs or difficult problems to overcome. If it's always easy, then you aren't challenging yourself, and you aren't growing as a programmer. Have the tenacity to keep working through a problem and not give up when it gets hard. But, also, know that you can take a break and come back to the problem in a little while. Maybe taking a break will help you solve the problem more efficiently or to see it differently when you come back to it.
You can learn so much from other programmers -- one person cannot know everything or anything close to it in the world of code. Be receptive to constructive criticism instead of defensive. You can improve your code and yourself from feedback, and being stuck in your ways doesn't lead to growth. You aren't always right, and you should be receptive to other people's ideas.
The first person that you need to have patience with when you are programming is yourself. Programming is hard and sometimes you will have bugs or difficult problems to overcome. If it's always easy, then you aren't challenging yourself, and you aren't growing as a programmer. Have the tenacity to keep working through a problem and not give up when it gets hard. But, also, know that you can take a break and come back to the problem in a little while. Maybe taking a break will help you solve the problem more efficiently or to see it differently when you come back to it.
Add a comment...
Post has attachment
“Method” is a pretty universal term, but you may encounter a C++ programmer who only knows it as “member function”. Conversely, Java may not have functions at all, depending on who you ask. “Procedure” and “subroutine” aren’t used much any more, but a procedure is a completely different construct from a function in Pascal.
Part of the problem here is that we’re not actually doing computer science. We’re doing programming, with a wide variety (hundreds!) of imperfect languages with different combinations of features and restrictions. There are only so many words to go around, so the same names get used for vaguely similar features across many languages, and native speakers naturally attach their mother tongue’s baggage to the jargon it uses. Someone who got started with JavaScript would have a very different idea of what a “class” is than someone who got started with Ruby. People come to Python or JavaScript and exclaim that they “don’t have real closures” because of a quirk of name binding.
Part of the problem here is that we’re not actually doing computer science. We’re doing programming, with a wide variety (hundreds!) of imperfect languages with different combinations of features and restrictions. There are only so many words to go around, so the same names get used for vaguely similar features across many languages, and native speakers naturally attach their mother tongue’s baggage to the jargon it uses. Someone who got started with JavaScript would have a very different idea of what a “class” is than someone who got started with Ruby. People come to Python or JavaScript and exclaim that they “don’t have real closures” because of a quirk of name binding.
Add a comment...
Post has attachment
Actions are small bits of code that can be run off of various GitHub events, the most common of which is pushing to master. But it's not necessarily limited to that. They’re all directly integrated with GitHub, meaning you no longer need a middleware service or have to write a solution yourself. And they already have many options for you to choose from. For example, you can publish straight to npm and deploy to a variety of cloud services, (Azure, AWS, Google Cloud, Zeit... you name it) just to name a couple.
Add a comment...
Post has shared content
Test Driven Development is development (design) driven by tests. In Test Driven Development we write the test before writing code to make the test pass. This is distinct from Unit Testing. TDD is much more than “Good unit testing”. Learn more about TDD: https://simform.com/what-is-tdd/
Add a comment...
Post has attachment
Post has attachment
Asking the right questions, to yourself and to other people, is a fundamental skill to be able to build something big and seamlessly. Those questions can come in the form of "why" in order to clarify requirements and prevent Over-Engineering or they can help to investigate the root cause of a problem. In the end, there's probably more value in having the right question than knowing the right answer.
Maybe investing additional effort into the journey for the right question can be worth it. Even if it turns out to be a waste of time, at least you have wasted that time in the question before starting to build the answer. Without the right question and jumping straight into the answer, you might as well be wasting a lot more of your time.
We should always move forward, one step at a time. What matters is not the speed, but the direction.
Maybe investing additional effort into the journey for the right question can be worth it. Even if it turns out to be a waste of time, at least you have wasted that time in the question before starting to build the answer. Without the right question and jumping straight into the answer, you might as well be wasting a lot more of your time.
We should always move forward, one step at a time. What matters is not the speed, but the direction.
Add a comment...
Post has attachment
Instead of looking at the solution, look at the problem. Instead of looking at the answer, look at the question. As engineers, we tend to measure progress as working hard. However, we need to work smarter. And that means to code less and think more incrementally.
Add a comment...
Wait while more posts are being loaded

