Books I wish I read earlier

When I wrote the review of The Manager’s Path I started to think about other books I wish I had read earlier. Usually these triggered some kind of change in how I approach my work or life. This list is definitely incomplete and I will add more to the goodreads list at the bottom of this post. Extreme Programming Explained: Embrace Change by Kent Beck I still remember when and where I read this for the first time. It was on a plane from the US OSCON back to London where I had my start-up. Up to that point all of our projects where waterfall and we basically had no unit tests in our code. On the plane I decided we had to do major changes and we did these over the next years. I was still pretty inexperienced in leading a team, but this was one step into the right direction. By now most of the things mentioned in the book, like pair programming, small cycles, unit testing, agility are well used and documented. This small book is probably still worth a read. Getting Things Done: The Art of Stress-Free Productivity This book is one of the ones where the solution is so obvious that a one page summary would probably enough. Nonetheless this is a good book and gave me a better idea about organizing myself. I am using a mix of the paper approach for all the paper one still receives and Todoist for everything else. In the end it is just a form of Kanban or Inbox Zero. It doesn't matter how you manage your tasks, just keep your work in progress small and your tasks prioritized. Web Operations: Keeping the Data On Time A collection of essays and interviews that gave me lots of ideas about DevOps and that side of a company in general. I still use it as a reference for things like post mortems. Because these are mostly stories it is an easy read and you don't have to read the book in sequence, just pick the ones that you find most interesting. Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity Mostly interesting and inspiring because I am so hopeless bad at this. As an introvert the idea of being candid and even worse radical candid seems absurd. But I know it is one of the areas I have to work on and the book gave me new ideas in a nice form. It is a bit long though and does repeat the main points over and over again. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses I am not working at a start-up any more, neither am I on the business side. I just wish we had this in my time in London. We would have avoided a lot of pain and would probably be still around now. Implementing this in an existing setting is a lot harder unless you have buy in from the top. The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change A great book for engineers transitioning to management. Another book I would have loved to have had at my start-up, thankfully it didn't exist back then. My review of The Manager's Path. Definitely worth reading for all developers even if you don't plan to go into management. I wish I read this earlier Web Operations: Keeping the Data On Time by John Allspaw Extreme Programming Explained: Embrace Change by Kent Beck Getting Things Done: The Art of Stress-Free Productivity by David Allen Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Malone Scott The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier Share book reviews and ratings with Christof, and even join a book club on Goodreads.

September 17, 2018 · 4 min · Christof Damian

Friday Links

John Resig: Write Code Every Day http://ejohn.org/blog/write-code-every-day/ Agilar: Scrum teams: self-organizing or self-directed? http://blog.agilar.org/index.php/2014/04/09/scrum-teams-self-organizing-or-self-directed/ etsy engineering youtube https://www.youtube.com/user/etsyengineering

April 11, 2014 · 1 min · Christof Damian

WeLovePHP Talk: Methodologies and tools used by the Splendia development team

Today I gave a talk at WeLovePHP, which is a quarterly talk and workshop series organized by Softonic in Barcelona. They also do one about JavaScript. I can highly recommend them if you are interested in PHP, JavaScript or related topics. I talked about the processes and tools we are using at Splendia. There are no pictures in the slides … sorry.

July 13, 2013 · 1 min · Christof Damian
A Code Review and Continuous Integration Workflow

A Code Review and Continuous Integration Workflow

As hopefully most people working on software projects nowadays we are writing unit tests and do code reviews. Work-flow at Splendia As our project is a large PHP site we are using PHPUnit for unit testing and various static code checking tools (checkstyle, phpmd, pdepend, phpcpd) to verify the quality of our code. All of these are run on our integration branch, whenever a new feature is integrated. Before this can happen the code will be reviewed by other people in the team and only if there is a consensus it will be merged into the integration branch. For the code reviews we are using the pull request system of github. It works very similar to other code review tools, you see a diff view of the changes and are able to add comments to discuss the code. In these comments we are using a convention of "+1", "-1" and "[B]" to give the pull request a thumbs up, down or mark it as blocked because a critical bug was found. Anyone in the team has a vote and is allowed to discuss any request. In addition to this the unit tests and some smoke tests will be run on the code of the pull request to avoid merging broken builds. Only if the tests are successful, there are three positive votes in total and no blocker the request will be merged. In the beginning all of this was done manually. Developers had to run the tests before the created the pull request and only senior developers had the right to merge a pull request. Every couple of hours they would check the list of pull requests and verify that they had enough votes. It was a distraction and also prone to mistakes. What gave us a big push in productivity was the introduction of two tools to the work-flow. ghprb First the GitHub pull request builder plugin, which enables Jenkins to automatically start a job for each pull request. It has additional features, like starting another build if more commits are added or recognising comments that instruct it to retest or white-list people who are allowed to create builds. It is similar to the pull request feature of Travis-CI only with the full possibilities of Jenkins to your disposal. With this we are testing every pull request before it gets merged. We also run a limited set of static code analysis, because we want to keep this build fast to give quick feedback. Currently it takes around seven minutes. PullRequester / plus-pull The second tool is a simple script which was written by one of our developers and it was called PullRequester. It runs as a cron job and checks whether the pull requests satisfy the +1 and successful test rules. If all is OK it automatically merges it. I have reimplemented this script to make it possible to publish it. You can find it under the name plus-pull on github. I have added some more features to make it also useful for open source projects. Final Words Even though these tools are not magic the increase of our productivity was visible. I account this mostly to way it enabled asynchronous working. No developer has to wait for a senior developer or poke someone to merge his code. As long as he can find three people who agree it will be merged automatically. And as everyone is interested in reviews themselves they tend to happen quickly. In the screen-shot you can see how this works in practice.

May 18, 2013 · 3 min · Christof Damian

Calm

Before:

September 1, 2011 · 1 min · Christof Damian