Chris James - Software developer

In Why "Build vs Buy" is the Wrong Question I explained how you should categorise your systems into appropriate "subdomains" (a la Domain-Driven Design), to help better understand whether to build or buy.

In big, enterprise IT departments, the question of build vs buy will often come up.

Accountability has a weight limit If the AI deletes all your business-critical data, you can't fire the AI.

William Martin forwarded me some written feedback on Learn Go With Tests from Kynan Ware which made my day.

I made The first commit for Learn Go with Tests (LGWT) on the 2nd of March 2018.

“Inspection to improve quality is too late, ineffective, costly.

The current state of web application development User expectations of the web are now that you have this super-smooth no-reload experience.

A colleague of mine is venturing into the magical world of Kanban, and one of the essential parts of Kanban is setting a "work-in-progress (WIP) limit".

I'm looking for a new software developer/engineering manager role, and this post will summarise me for potential employees.

Work has been a mixture of a lot of highs and lows.

For several years, I had an ambition to speak at some kind of Gopher conference event, especially to talk about testing, which is a subject that is so misunderstood.

Poorly managed work in progress (WIP) is a common cause for low performance in development teams.

When working with people who are learning test-driven development (TDD), I have a habit of talking about “the hat we’re wearing”.

I was lucky enough to have a second appearance on the Go Time podcast a few weeks back.

David Wickes wrote an excellent post called Three Books, which claims that any senior developer should be able to recommend three books to a less experienced colleague.

No matter what my role is within a company, I want to work in an empowered, trusted, team that works together to deliver things we can all be proud of.

Many people have false starts with test-driven development (TDD).

I was lucky enough to be invited on to the Go Time podcast to talk about Introducing your team to Go.

I recently redesigned this website.

A lot of developers are very vague when they name their test doubles which makes tests needlessly more difficult to understand.

This post is a summary of work stuff over the past year which covers my first adventures into Technical leadership and line-management Hiring and building a brand new team I think I've helped build a pretty rad team, so if you're interested in that kind of

If you read the internet, you'll soon realise that a large number of software developers don't understand what CI is and why it's important.

Stumbled across https://www.websitecarbon.com which measures the carbon footprint of your website.

People talk a lot about "lean".

This is another follow up post to an episode of Go time I listened to the other day which seems to get my creative juices flowing.

The Go Time podcast on functional programming (fp) was an interesting listen and as someone who has done many years of both Scala and Go it's a topic I'm interested in.

This article is for anyone who works in software and wants to keep life simple, less stressful but still keep their employer happy.

This post is a summary of work stuff over the past year which covers The ways of working, agile and innovation Microservices vs monoliths Kotlin Writing a book (kinda) The team and the way we work I rejoined Springer Nature (SN) August 2017 on the exciting

This month I had the opportunity to present some ideas floating around in my head around tests, refactoring and design at the Go London User Group.

I originally posted this at Dev.to, where you can see some comments This post will very much sound like I want you all to get off my lawn - because I do.

I originally posted this at Dev.to where lots of people agreed and disagreed.

[:fa (take 9 (repeat :la))] This post is aimed at beginners who want to take a look at Clojure, a super-interesting language which is probably quite different to what you’re used to.

When it comes to prioritising work you may find yourself in an environment where it can feel hard to justify playing "technical" stories.

People talk a lot about how to write testable code but testable systems are what you need if you are going to be able to practice continous deployment.

I was given a fairly mundane task at work and when this happens I try and find ways to make it interesting.

Sometimes you may need to test that an asynchronous event has been triggered in your code but you can end up compromising on the quality of your tests when doing so.

Most property-based test examples you see on the web are contrived scenarios and people can be dismissive of them, claiming that they aren't actually practical.

Magic is often used to describe confusing code.

This posts hopes to illustrate What property based testing is and why it is an important tool to compliment your existing tests How easy it is in Go Your current tests The usual examples illustrating TDD could be described as example based tests; where you

Why do developers whine about doing estimates?

The Happy path of writing software is usually the easiest part and coincidentally is the the thing focused on most during estimation.

SpringerLink is the biggest project I’ve been involved with.

I can’t sell these books well enough, which is why I’m not an author or a salesman.

What’s rad about writing Go is how the tooling is really well catered to every day software development concerns.

Type systems are great because they protect you from lots of errors at compile time.

Technical debt is often described on a low level, where developers will take some kind of shortcut in order to deliver a feature quicker; at a cost to future development which must be "paid" sometime.

Last week Dan and I did a presentation at the Springer offices for the Functional Media meetup about our experiences with Scala.

After nosing through some Scala FP books I have been trying hard to write small and simple functions and then compose them together.

I have been reading the book Javascript Patterns, which is fairly easy reading and I would recommend it if you wish to understand Javascript a little better.

A number of my friends are cool enough to take an interest in what I do and even go as far as to want to try and understand it.