Hi there!

As you might know, I haven’t posted anything to TDD Fellow blog for quite a while. I wasn’t just lazy. I have been severely busy.

I was busy creating new things.

Guest Blogging

I’ve written a few guest blog posts, for example this guide might teach you how to make better decisions as a software developer. That article is about stress, willpower, mental health and results in a work of software developer.

Right now I’m writing another guest blog post and talking to more blog authors looking for guest posts.

Reading Complete Software Developer’s Guide

Also, I’ve read an amazing book, best seller in Software Engineering category, that I predict will become one of the classics of Software Engineering, alongside Refactoring and Patterns books - The Complete Software Developer’s Career Guide.

I loved it. It is a book for a software developer of any stage: beginner that is just learning, professional trying to land THAT first job, competent professional software developer itching to improve or an expert software engineer looking for ways to transcend and go beyond a simple software engineering role? Then this book is for you. Read my full review on the Amazon.

Stories on Productivity, Negotiations, and Stress

(for software developers)

I’ve started a whole series of stories and case studies (I call them “War Stories”) on productivity, negotiations, and stress for software developers. So if you want to learn how to negotiate, be productive and handle stress as a software developer, go and grab my stories.

The stories are published under the name of “Productive Developers Only.” One might think: “What a cheesy name!”. I love the name, though. Hehe :) It is not just for Productive Developers Only, it is also for anyone who wants to be more productive, more successful and healthier as a software developer.

So far, I’ve written one case study called “How to Get a Better Offer Accidentally.” It focuses on one simple negotiation technique. In fact, there were already two revisions of that story. And I’ve received some more feedback from my dear friend and colleague Alexis. So I’ll write the third version soon, and it’ll rock! By the way, check out Alexis’ blog: Free is a Verb - it is amazing!

Also, I’m in the process of interviewing a few developers for the next case study called “Why You Need to Work Four Hours Only Per Day.” In fact, you are not working more than four hours per day, even if it takes you eight or more. Isn’t it surprising? If you want to know more, hurry to grab my stories, and you’ll receive the case study as soon as I publish it in a few weeks.

If you are still reading, I’ll throw some more interesting teaser at you ;) How about I tell you what first case study was about?

Julia’s Story

Julia was searching for a first job as a developer after graduating. It was tough, as most companies wanted to hire experienced developers. Julia didn’t lack qualifications for the junior positions. She was interviewing with two startups in her hometown.

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.

Welcome back to the new issue of “Build Your Own Testing Framework” series! Did you notice, that out testing framework quits on the first failure? It probably should run all tests, collect all failures and present them nicely. This is what we are going to accomplish today:

• Make sure all tests run even when there is a failure.
• Make sure exit code is correct.