IDE tips to save you from disaster

5 Features to save you from Disaster

I'm working on creating a training course for IntelliJ IDEA (I've been working on it for a while now, I don't really want to talk to much about it because I'm not sure when I'll actually deliver it). Anyway, as I was thinking through Features You Really Need To Know, I realised that it's not really about code completion and code generation, it's about those features that will get you out of a big, deep hole that you've dug yourself into.

So, I put together my top five features that have saved my bacon, and recorded a video for the Continuous Delivery channel. I have asked around and these features should work for all JetBrains IDEs, not just IntelliJ IDEA.

As usual, I have included the transcript below so you can skim it and skip to the bits that interest you.

Read more

Reading Code Is Hard, and tips to improve

We spend more time reading code than writing it

This week's video for Dave Farley's Continuous Delivery YouTube channel is me ranting about why reading code sucks, and offering some advice on how to improve.

"Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. They read over the lines, and weep at their beauty…."

https://www.stilldrinking.org/programming-sucks

The original idea for this video is from my presentation Reading Code Is Harder Than Writing It, and from my blog post Reading Code is a Skill, an older post which has only become more relevant in the modern age of AI.

Read more

Flaky tests are poisoning your productivity

Picture of Trisha's face frowning and the title "Flaky Tests"

I freaking HATE flaky tests.

The first time I worked in an environment that had real Continuous Integration with Actual Automated Tests that Actually Ran, it was like... freedom. We literally got the green light that our new code was working as expected, and that any changes we made hadn't broken anything. And refactoring... before then, I don't think I had ever really refactored anything. Even a simple rename was fraught with danger, you never knew if reflection or some sort of odd log-file parsing was dependent upon specific class or method names. With a comprehensive suite of unit, acceptance and performance tests, we had this blissful safety net that would tell us "Everything Is OK" after we'd done simple or extensive refactoring.

Except.

Read more

Why I prefer trunk-based development

Photo of a tree at the side of the river in Sevilla, Spain

These days, distributed version control systems like Git have "won the war" of version control. One of the arguments I used to hear when DVCSs were gaining traction was around how easy it is to branch and merge with a VCS like Git. However, I'm a big fan of Trunk-Based Development (TBD), and I want to tell you why.

With trunk-based development, all developers work on a single branch (e.g. 'main'). You might have read or heard Martin Fowler or Dave Farley talking about it. It was when I was working with Dave (around about the time that Git was rapidly becoming the "go-to" version control system) that I really saw the benefits of trunk-based development for the team, particularly in an environment that was pioneering Continuous Delivery - Dave was writing the book with Jez Humble while I worked with him.

In contrast, the branching model encourages developers to create separate branches for every feature, bug fix, or enhancement. Although branching may seem like a logical approach to isolate changes and reduce risk, several factors make me more comfortable with trunk-based development.

Read more

“Simple” Network Connections with Java – a problem

I've been playing with NIO for network stuff to see if/how I want to update the code for Head First Java 3rd Edition. The original code used Sockets and Readers/Writers, and I thought there must be a more "modern" way to do this so I've tried updating it a few different ways. I got it working using SocketChannel and ByteBuffer (eventually!), but the ByteBuffer stuff is just too fiddly to use to teach people basic network IO in Java. After turning to Twitter for the answers (Twitter Driven Development) I had what looked like a promising hybrid approach.

However, I've run into a problem with using the Channels factory methods to provide this nice bridge between NIO (SocketChannels) and classic streaming IO.

I'm posting the code here because you can't post source code this long on Twitter! Maybe someone can help me.

Read more