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.
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 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.
The first startup was one step ahead of the second in the interviewing process. Let’s give them names: “Milky Way” and “Stardust.” On Monday, Julia had an interview with Stardust. She liked culture, people and enjoyed the interviewing process.
On Tuesday, Julia had the last interview with CTO of Milky Way. Same evening she got an offer from them. HR Consultant Peter wanted an answer to that offer as soon as possible. Preferably - immediately, the same evening.
Julia told him: she’ll be able to decide only on Friday afternoon. After all, she had a final interview with Stardust’s CTO on Friday. Peter didn’t like it and insisted. Julia firmly kept her decision. What happened Friday morning nobody could anticipate.
To know what happened Friday morning grab negotiations “War Story”: How to Get a Better Offer Accidentally!
What’ll happen to TDD Fellow Blog?
It’ll have more content! I’m going to post technical, architectural and TDD related topics here from time to time.
For example, I’m drafting out a blog post about Clean Microservices Architecture right now. Just to tease you a bit:
Clean µServices Architecture
Ever worked in a µServices environment and needed to refactor across services? You need some slow integration tests that run against the whole deployed system to make sure your refactoring didn’t break anything. These integration tests make for a slow and annoying feedback loop, which discourages that refactoring!
What if you could launch your whole application as a Monolith on your local machine and run acceptance tests that are as fast as unit tests? And you could deploy the same system as a bunch of µServices? Come and learn about Clean µServices Architecture!
You would not want to miss that blog post. So make sure I can notify you when the article is up:
Thank you so much for reading this article! If you liked it, please share this article on social networks, Reddit, and Hacker News, and follow me on Twitter: @waterlink000.
If you have any questions or feedback for me, don’t hesitate to reach me out on Twitter: @waterlink000.
And don’t hesitate to take a look at Productive Developers Only!