“So, what software engineering practices do you like to use?” — I asked another developer the other day. And the answer has wholly shaken me:

“What do you mean by “software engineering practices?” — was the developer’s response.

When I explain what I mean by these three words (apparently, I took for granted), the person starts listing technologies. This conversation has been repeating a bit too frequently for my liking recently.

Look, I get it. Technologies knowledge and experience are vital for a software engineer. However, the fundamental practices of software engineering are insanely important nevertheless.

Let’s discover why.

As software engineers, we tend to be lifelong learners. Suppose our current job becomes less challenging, and there is nothing more to learn. In that case, we usually resort to one of the following:

• Find a more exciting team or company.
• Start something on the side in our free time.
• Bring more advanced concepts to the current team and codebase.

It’s the third one that is the most worrying because it happens way too often, and it’s probably more harmful than you think.

Hi there! Today I want to share the technique that we are using to improve the collaboration inside of our teams. This technique is most useful in synergy with the pairing. It is so powerful that it can remove the tension from our work and make us more productive in two or three days.

First, let me give you some context.

Hi there! Today I want to share my experience of a productivity shift from the late evening/night to the morning. First, let me tell you a story on how my day was structured before for countless years.

Mornings That Start with a Lunch

Did you ever look at the chunk of code that is not very pretty, and immediately uttered some bad word or bad remark, such as “Who wrote this?” And not even noticed it?

Or did you ever had an incident happening in production, and half of your vocabulary at that time was not normative? Also, did you feel stressed and down afterward?

Or did you ever had to converse with a difficult person or someone holding a strong opinion, and thought not very good about them? Or even dismissed a valid argument just because you didn’t like the conversation?

Did you ever felt or did something negative, and thought afterward that it would be better not to? Then the technique described in this article is perfect for you!

Welcome back to the new issue of “Build Your Own Testing Framework” series! When trying to implement better formatting, we have discovered that some of our test suites do not run all tests! Today we are going to fix that, and we will make sure that such test suite will fail if it didn’t execute all tests.

Level: Beginner

Today we are going to learn the basic principles behind the Test-Driven Development Discipline. We will learn three rules of TDD. We will learn what are the benefits of doing Test-Driven Development. And we will take a look at the example application of these laws.

" feedback "  (CC BY-SA 2.0)  by Sonti Malonti

Level: Beginner.

“Learning TDD with Javascript” is the series of articles where we learn basics of automated testing and test-driven development. While the language of choice for the code examples is Javascript, all described concepts are language-agnostic and are applicable in various technological stacks. In these articles, a reader is expected to do small exercises after each major topic to reinforce that theoretical knowledge with practice. Some of these exercises are practical and will involve coding, or simple writing; others will be food for thought. Also, a reader might want to get their feedback on these exercises, so don’t hesitate to send the results my way: oleksii@tddfellow.com - feedback on the practice is quite important as it helps to improve quicker, when you know what is well and what can be improved and how. Also, don’t hesitate to send any questions and feedback regarding the content of these articles. Your questions, feedback, and your practical results will help authors shape this content better.

Today we are going to learn how to write tests that imitate real user interaction for the whole application. We are going to build a small web application using Vanilla Javascript. Vanilla Javascript is a plain Javascript without any framework or library. Such tests that imitate real user interaction via User Interface (UI) are called End-to-End Tests. These tests are the most simple to write because we only need to think about our application in the same way user does:

• Imitating the user clicking on the button would mean for us to trigger a button click;
• Imitating the user typing text in the input field would mean for us to change input’s value;
• Imitating the user clicking on the link would mean for us to trigger a link click;
• And so on.

Have you ever worked with mobile platforms, such as Apple Store or Google Play? How much time it takes to release a new version of the application? They have ~2-4 days manual review of your mobile application. What do you think that means? - You can release your application to production no often than two times a week. It became much better around this year - before it was 1-1.5 weeks.

Today we are going to learn how to eliminate the fear of changing legacy code. We will learn how to confidently and in small iterations understand the legacy code better while increasing the test coverage in the process. While code examples are in Ruby programming language, the technique applied is language-agnostic.