Reading code
As developers, we spend a lot of time learning to write code, while spending little to no time learning to read code. Meanwhile, we often spend more time reading code than actually writing it. Shouldn’t we be spending at least the same amount of time and effort improving this skill? Deliberate practice can help us get better at reading code. Learning how to better read and understand code, can in turn teach us what makes code readable. This might even help us to write code that is easier to read.
In this talk we will discuss the benefits of deliberately practicing reading code in a code reading club or session without an IDE, as well as common strategies to navigate a new codebase and familiarise ourselves with the code using the IDE.
Keep your dependencies in check
If Log4Shell, Spring4Shell, etc. have taught us anything, it’s that we need to keep our dependencies up to date. But updating our applications can take a lot of time. How do we stay on top of that, while also continuing to deliver business value?
Luckily, there are plenty of tools that can help us with this, from package managers to bots that can automatically create changes on our repositories. Let’s go over some of the different options, so we can make informed choices about what’s best for us in a particular situation.
Will AI Assistant make developers redundant?
IntelliJ IDEA already had plenty of smart features to make developers’ lives easier: code completion, tool integration and more.
Now with JetBrains AI Assistant you have the power of LLMs right inside your IDE. Let’s take a look at how the knowledge your IDE has about your project combines with the power of LLMs to enhance your coding workflow. We’ll look at what JetBrains AI Assistant can do for you, and what it can’t (yet?).
Will AI Assistant make developers redundant? Come and find out.
public static void main 🎶
(Joint presentation with Hanno Embregts)
Why just type the words “public static void main”, when you can also sing them? This talk-slash-pop-quiz is about 15 songs that will work with “public static void main” as the lyrics, enabling you to fully enjoy writing main methods while impressing your colleagues with your musical creativity at the same time.
Tools to help keep your dependencies up to date
Log4Shell and Spring4Shell were found while I was working as a Software Engineer at a Dutch online retail platform and we had to urgently upgrade all of our microservices. We were already using a dashboard showing SCA scan results, and we added Renovate to all our repositories to automatically create Pull Requests to upgrade dependencies.
Of course, some upgrades require changes to the code as well. Let’s take a look at the tools at our disposal that can help keep our dependencies up to date!
Code reading (workshop)
As developers, we spend a lot of time learning to write code, while spending little to no time learning to read code. Meanwhile, we often spend more time reading code than actually writing it. Shouldn’t we be spending at least the same amount of time and effort improving this skill? Deliberate practice can help us get better at reading code. Learning how to better read and understand code, can in turn teach us what makes code readable. This might even help us to write code that is easier to read.
In this workshop we will practice our code reading skills by reading an unfamiliar piece of code, using structured exercises. Participants will practice reading code, and take away knowledge about how they can continue to improve this important skill.
Use Testing to Develop Better Software Faster
Testing doesn’t always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)
As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.
Collaborating on Open Source Software; or How I started contributing to Open Source and why you should too
There are several reasons you might want to contribute to open source software. For me, it was that I wanted to learn in a more useful way than doing programming challenges. So I looked into how I could contribute to open source projects that I use myself.
After contributing for almost two years, I notice that I have learned a lot from my contributions (which has been useful at work), as well as have made friends and have become part of a community.
In this talk I will share my experience with contributing to Cucumber, including an early mistake (merging something that wasn’t ready yet) and fixing it with the support of core maintainers, and still feeling welcome!
You’ll learn how how to find your project and contributions to start with, how to connect with the community to make sure your contributions are useful and the many different types of contributions you can make.
Contributing to open source is a way of giving back to the community. In addition, it is a way for you to learn, collaborate and become part of a community. Getting (constructive) feedback on a pull request and collaborating to make things even better is a great feeling!
What to do when your automated tests start to slow you down
Contract testing is an increasingly popular approach to make sure different services work well together and don’t break agreed upon contracts between services. The team I joined last year was using Spring Cloud Contract Testing as a tool for this.
But with 206 contracts for only 15 other services, the contracts weren’t used for their intended goal of making sure the mocks we test against are valid responses of other services; they were used to test different scenarios inside our own service. To make things worse, the other services were not even using the contacts to make sure they didn’t break their API; we had no guarantee these contracts were valid! The time waiting for these tests to run became a pain point. The “contracts” were just expensive mocks; time-consuming to initialize, run and maintain.
In this talk, I will tell you how we replaced unreliable and time-consuming tests with faster tests and faster mocks, while increasing test coverage and decreasing our build time. You will learn how to look at your testing needs and your architecture, designing automated tests as feedback mechanisms that provide the right information at the right time, by using the right place for each test rather than adding tests into default boxes. This might help you think about your test strategy, and what to test where and how.
Building a software quality mission statement (workshop)
Software Quality means different things to different people in different contexts. In this workshop we would like to explore these different meanings of software quality. We would like the participants to share their perspectives with each other and, from those, build a shared mission statement for software quality.
We will introduce techniques to get to a shared mission statement. The techniques we will be using are based on the process that Cucumber Ltd. went through to create their company mission statement.
Great test automation does not absolve you from manual/exploratory testing
In recent years we’ve seen a movement to more test automation replacing manual/exploratory testing and even replacing dedicated testers altogether.
Many programmers don’t like to manually test things. But not everything can (or should) be automated. Some things are hard if not impossible to automate, others are simply not worth the effort.
I’ll illustrate this with a tale of a new system built by my team where we still found bugs in e2e testing even though we had solid unit and integration test coverage.
Great test automation does not absolve you from manual or exploratory testing. We’ve seen there’s more automated testing than doing manual testing.
I’ve seen people, companies, teams move away from having dedicated testers at all, and I’ve even heard people say, you know, you should never do any manual testing at all. I have an opinion on that.
Now, I don’t like manual testing, especially manual regression testing; I think it’s very boring! So, when I got into test automation about five years ago, I was like “automate all the things!” Because automation is fun, you know?
I get to write code, listen to Spotify, and get paid to do that; it is awesome! However, I met lots and lots of awesome testers, and I learned that maybe we cannot automate everything.
Some things are just too hard, too brittle, it takes too much work; it’s more work automating it than it would be to do it manually, especially if you have to maintain those tests (which I have done).
Automation can’t tell you what it’s like to actually use the thing. To quote my friend Lanette Creamer: “If you don’t test it, your users will.” And what does that say about how you value your users?
Joy of acceptance test automation with Cucumber
Joining a Scrum team as the first tester was challenging, since I’m not a ‘traditional’ tester. My test experience is in automation, while the team was expecting manual regression testing.
Early on, I introduced Cucumber; a Behaviour Driven Development (BDD) tool to automate acceptance tests.
This talk will highlight the intended – and unintended – benefits using Cucumber has brought to my team. You will learn what Cucumber could do for you, and when not to use it.