If you ever tried TDD and failed, you’re in the right place.
I’m going to help you understand the true meaning of TDD and how to apply this philosophy in your daily work.
Includes private GitHub repository with all examples and exercises
Requirements
5+ years of experience in software engineering
Target group
Senior software engineers (5+ years)
FORMAT
Video course + private GitHub repository
OUTCOMES
- Master the art of focus to maximize your efficiency
- Have tools to understand and model business correctly
- Create better software design
- Become proud and confident of your job
Lessons
See the free lesson!
The first chapter is all about the true meaning of TDD. You will learn that TDD is not about testing your code, but rather about driving the design of your domain model according to
- 7 lessons total
- Summary
- Questions and exercises
More advanced topics are covered in Chapter 1
6 lessons total
- Lesson 0: Take a deep dive into the internals of TDD. Learn about the unit ambiguity on different levels: method, class, module and service.
- Lesson 1: Learn the differences between two schools of TDD: the Chicago School and the London School.
- Lesson 2: See how Event Storming, Example Mapping and TDD can be combined together to build better domains models.
- Lesson 3: Learn how to find the right TDD iteration cycles by following some simple rules. Rule: Don’t write dumb code
- Lesson 4: Learn how to find the right TDD iteration cycles by following some simple rules. Rule: Reuse generic concepts
- Lesson 5: In this lesson you will learn how your domain expertise can impact your TDD scope. This is the very last lesson of the TDD course.
We often consider business and developers as separate teams. The “Business” part needs something, while “Developers” implement it. This clearly defines the Customer-Supplier relationship at best and Conformist at worst. In these relationships Business acts as Upstream, while Developers as Downstream. Doesn’t sound like the best option when developing custom solutions, does it? I’m going to show you how to upgrade this relationship into Partnership.
In this course I’ll show you how you can become a Technical Business Partner. Technical Business Partner is a business-oriented engineer with deep technological expertise. Instead of just implementing stuff correctly, TBP understands the business and therefore is able to suggest improvements in the business model or any other aspects of running the company. This approach allows us to build better models, increase velocity of the development and focus on what’s really important instead of wasting time and energy on technological bikeshedding.
Note: this course is still in development. Buy now to get early access to all future lessons for the best price!
Requirements
10+ years of experience in software engineering and having a business mindset
Target group
Architects, Principal Engineers, Staff Engineers, very ambitious Junior Engineers
FORMAT
Video course
OUTCOMES
- Become a business partner, not just a regular engineer
- Learn tools to help you understand business: Wardley Mapping, Product Vision Board, Context Maps, User Story Mapping and many more
Lessons
See the first lesson for free!
Take your first step into becoming a Technical Business Partner!
