Why Unconferences are Superior to Conferences
Fresh from the exhilarating Web Engineering Unconference Europe (#WEUC), my appreciation for the unconference format over traditional conference setups has been rekindled. Don't misunderstand me — I do relish well-organized conferences. However, when faced with a choice between a conference and an unconference, my preference is unequivocal.
Best of: Posts I Still Refer Regularly to My Engineers
I recommend a bunch of blog posts we (Qafoo) wrote regularly to new engineers (mainly PHP, but also JS) in my teams. This is the currated list for future easier reference.
From Algorithms to Anxiety: A Tech Leader's Mental Health Coming Out
Mental health challenges don't prevent leadership. In fact, leaders should be open about their mental health, acting as role models and creating environments that support healing and understanding. This is my coming out.
Injectables vs. Newables
Many projects I join - even those that claim to already do dependency injection - suffer from issues that result from mixing injectable and newable classes. Keeping these two appart seems to be challenging for many developers so that I try to give them a handy guide with Do's and Dont's in this blog post.
Methods Of Teaching
There are many different ways to teach topics of software developments. From recorded lectures to pair programming. Over the time we tried many of them with different customers and different topics. I want to provide you with an overview of what worked best for us for which topic.
Five Tips to Improve Your Unit Testing
After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.
Refactoring with the Advanced Boy Scout Rule
When we join teams to coach them with refactoring their legacy code base, many of them are overwhelmed by the sheer mass of code. That typically results in the request for "some refactoring sprints" or even "a complete rewrite". Both is obviously not a solution from the business perspective - feature development and bug fixing needs to go on and the refactoring should not eat up the larges portion of time. But where and how should the team start and how should? What we call the "Advanced Boy Scout Rule" has helped many teams to come over this staleness and reach fast results while continuing to deliver business value.
Loving Legacy Code
Many developers want to "rewrite the whole application" and "get rid of all that sh*t". Most of them are pretty blank when I tell them that I really like working on such code bases, even if I just jumped into the code. I recently talked about that to the other Qafoo members and all of them agreed to my views. Therefore I want to explain our love of legacy code in this post.
Extracting Data Objects
Extracting data objects from your code will make it easier to read and write, easier to test and more forward compatible. This post shows you the two most common cases where introducing a data object makes sense and how to do it.
Refactoring Should not Only be a Ticket
In this blog post I would like to elaborate a bit further on why refactoring should never only be a dedicated task on your board. It should be an essential part of every task you work on…
Getting Rid of static
When people start (unit-)testing their code one of the worst problems to tackle are static calls. How can we refactor static calls out of an existing application without breaking the code and while producing new features? How can we get rid of this big test impediment?