Colin Breck

A year ago, I accepted a team lead position. As I wrote at the time [https://blog.colinbreck.com/on-being-a-team-lead-welcome-to-our-team/], I have had a number of opportunities to be a team lead, but I have always declined them, choosing a more technical role, to become a better engineer. In this

I expand on these concepts in my Reactive Summit presentation [https://www.youtube.com/watch?v=qaiwalDyayA]. Most people are attracted to Akka with the promise of the actor model providing a better abstraction for building scalable and resilient distributed systems. Since Akka attempts to solve such a challenging set

I expand on these concepts in my ScalaDays presentation in Berlin [https://www.youtube.com/watch?v=ilhImUjF53A] and New York [https://www.youtube.com/watch?v=hpQJLQ_8N1c]. I have spent my entire career building infrastructures for streaming data to support the monitoring and control of industrial applications. I

I expand on these concepts in my ScalaDays presentation in Berlin [https://www.youtube.com/watch?v=ilhImUjF53A] and New York [https://www.youtube.com/watch?v=hpQJLQ_8N1c]. I have been using the Akka Streams API [http://doc.akka.io/docs/akka/2.4.16/scala/stream/stream-introduction.html]

This article was the basis for my talk at QCon London 2017 [https://www.infoq.com/presentations/quality-views-technical-debt]. I also wrote a follow-up article Reflections on Using Quality Views [https://blog.colinbreck.com/reflections-on-using-quality-views/]. I have worked on infrastructural software my entire career—mainly streaming-data systems [https://blog.colinbreck.com/

Making the transition from procedural, synchronous programming to fully-asynchronous programming, can be challenging. Or, it can be quite easy. If all of the languages, frameworks, and services that you are using naturally support asynchronous programming, it can be straightforward to adopt, making it easy to build scalable applications. The biggest

The Akka actor-model framework provides convenient libraries for application logging [http://doc.akka.io/docs/akka/current/scala/logging.html]. As one would expect, there is support for configurable logging levels—error, warning, informational, and debug— and log messages are written asynchronously for good performance. There is a subtle performance

Software developers stereotypically hate meetings. Personally, I do not dislike meetings. In fact, I quite enjoy interacting in meetings. What I dislike is when meetings disrupt my day, slicing it into small increments, such that I have no time for extended, focused work. I have tried to voice this concern

The team [https://blog.colinbreck.com/on-being-a-team-lead-welcome-to-our-team/] that I work on has been trying to hire for a while now, so I've been going through a lot of resumes. I've seen hundreds of resumes in the past few months and I can't think of

I have written a few articles [https://blog.colinbreck.com/sharing-tests-and-generating-tests-in-scala/] describing how I like to write automated acceptance tests with descriptive test names that read like a specification. These tests not only ensure the quality of the software, but they also act as documentation, and they become a focal

Joel Spolsky's article The Iceberg Secret, Revealed [http://www.joelonsoftware.com/articles/fog0000000356.html] is, for me, one of his most memorable articles. He frames the situation as follows: > "I don't know what's wrong with my development team," the CEO thinks

I've had a few opportunities to be a team lead, but I've always declined these opportunities. Sometimes it was because I felt the project or the timing just wasn't quite right, but, as much as anything, it was because I wanted to keep developing

It has been two years since I started this blog [https://blog.colinbreck.com/inaugural-post/]. A year ago, I reflected on the first year [https://blog.colinbreck.com/test-driven-career-development/]. I have averaged an article a month, this being number 24. I try to post an article in the first week

I have written before [https://blog.colinbreck.com/in-defence-of-testing-one-thing-per-test-method/] about how I like an automated test to test only one thing, have one clear assertion, and have a descriptive name that reads like a checklist item in a specification that can be understood by someone who is not a programmer,

In my last article [https://blog.colinbreck.com/practising-empathy-in-technical-interviews/], inspired by Indi Young's book Practical Empathy [http://rosenfeldmedia.com/books/practical-empathy/], I proposed that we might expand the thinking and effectiveness of our organizations by developing empathy during a technical interview, through what Indi calls a dedicated listening

I would like to propose an experiment for improving the effectiveness of technical interviews: developing empathy for the candidate through a dedicated listening session. Previously, I shared my thoughts on incorporating code review in technical interviews [https://blog.colinbreck.com/interviews-for-programmers-should-involve-code-review/] as a means of developing empathy, to increase the

In my last article [https://blog.colinbreck.com/automatic-resource-management-in-scala-revisiting-test-context-classes/] , I explored automatic resource management in Scala by developing test context classes to reliably manage resources in functional tests. I have explored the topic of test context classes a few times, and each time I focused on using these classes purely

I have written previously about how I like to use what I call call context classes for functional tests in order to encapsulate test setup, reliably cleanup resources at the end of a test, and to promote code reuse across tests. I started by writing about using disposable objects for

The debate over whether to write a unit test or an end-to-end test for an aspect of a software system is something I've encountered a number of times. It most often arises as a philosophical discussion along the lines of: If we can only write one test for

I am going to be using the Scala [http://www.scala-lang.org/] programming language for some upcoming projects. This will be my first time using a functional programming language and my first time developing for the JVM. Up to this point in my career, I've primarily used C+

I have been part of the interviewing team for my employer for over a decade. Over this time, I've conducted hundreds of technical interviews for programmers. By far the best advice I've ever read on technical interviewing is Joel Spolsky's The Guerrilla Guide to

I was asked, recently, to recount the most difficult bug that I have ever encountered. I have worked on distributed systems for some time, including a multi-threaded, distributed system written in C++, which is used in diverse and demanding industrial environments. So, needless to say, I’ve encountered more than

When I complete something that I'm working on, rather than calling it a day, I usually start on the next thing. Not in the hopes of finishing a great deal more work, usually it is just to get a feel for what is in store next. Nothing is

For over a decade, I have worked on infrastructure software for streaming data systems. My experience includes developing and supporting time-series databases, publish-subscribe messaging systems for streaming data, and software for reliable event-data collection. As they are embraced by web companies for making operational and business decisions on-the-order of minutes

I started this blog [https://blog.colinbreck.com/inaugural-post/] a year ago with the intention of sharing some of my work. I think it has gone roughly according to plan. I'm satisfied that I averaged an essay a month — that feels about right for me. Looking back, there