DEV Community: grzegorzgrzegorz

U-Groovy

grzegorzgrzegorz — Thu, 01 Jan 2026 15:58:08 +0000

I have been working with Jenkins pipelines for extended period of time. Because Jenkins supports Groovy libraries it was also time I have been using Groovy much. As now I am moving more to Java world it is good time for a short summary of the capabilities of this language. In my view Groovy is a U-language: unknown, underrated and unnoticed. Many people heard about it but only few know how handy and universal it is. I would like to change it a bit.

In general, Groovy can be like Java. It is JVM language but also it understands pure Java code. This is one of the benefits as Java people can use it instantly. In contrast to Java, it can be used in the context of the most, if not all, programming paradigms allowing for almost free structuring of the codebase. Let me show you few very simple examples to illustrate how flexible it is.

A. Imperative programming.

This is when commands are used to describe how the program performs step by step. It seems to be the most popular way to write computer programs.

1. Scripting language.

Groovy can be used as plain scripting language. You can write instructions one by one to achieve the desired result. This is like bash:

println "this is just plain scripting"
a = 1
b = 2
println a + b

2. Object oriented programming with dynamic types.

One can go into OO world and use objects with dynamic types like this:

class Car {

    def regNumber = "123AB"
    def numberOfStarts = 0
    def weight = 2

    def start() {
        numberOfStarts++
        println "running"
    }

    def stop() {
        println "stopping"
    }

    def getRegNumber() {
        return regNumber
    }

}

def car = new Car()
car.start()
car.start()
assert car.getNumberOfStarts() == 2
println car.getRegNumber()
car = "this is car"
println car

When static typing is overkill you can simplify the code and avoid it. Dynamic typing also means you can assign multiple value types to the same variable like def car. It may also return different types from the same def method() as the type is selected during runtime only (not shown in the example).

3. Object oriented programming using static types.

One can be more like Java developer and use static types as well (notice, this is not Java, as no semicolons here):

class Plane {

    String regNumber = "123AB"
    int weight = 20
    int numberOfFlights

    void fly() {
        numberOfFlights++
        println "flying"
    }

    void land() {
        println "landing"
    }

    String getRegNumber() {
        return regNumber
    }
}

Plane plane = new Plane()
plane.fly()
plane.fly()
assert plane.getNumberOfFlights() == 2
println plane.getRegNumber()

B. Declarative programming.

In declarative programming one does not write instructions one by one but describes the desired end result instead.

1. Groovy based declarative syntax.

It is possible to create the syntax for custom declarative language and use it as needed in Groovy:

println "declarative programming"

def surroundedWithDashes(closure) {
    println "-------------"
    closure.call()
    println "-------------"
}

def show(closure) {
    println closure.call()
}

def sumOfNumbers = { a, b ->
    return a + b
}

surroundedWithDashes {
    show {
        sumOfNumbers(3, 6)
    }
    show {
        sumOfNumbers(1, 2)
    }
    show {
        sumOfNumbers(5, 10)
    }
}

Technically this example is basing on closures and from developer point of view, after the syntax is ready, it is enough to say surroundedWithDashes to get the layout accordingly.

2. Functional programming.

One can use Groovy in the context of functional programming paradigm as well which means using functions which accept some input and for the given input they always produce the same specific output without any side effects.
In Groovy, most results can be achieved by using just 3 functions:
collect, findAll and inject.
Here is the example with the first two:

println "functional programming"
def data = [1, 5, 8, 3, 5]
def result = data.collect { item -> item + 10 }
        .findAll { item -> item > 13 }
        .toUnique()
assert result == [15, 18]

The benefits come not only from function chaining but also from functional programming related capabilities like:

memoization - caching the results of the function for the given inputs
currying - creating functions from simple, generic ones

C. Metaprogramming.

This maybe should not be separate section in the context of programming paradigms but I really would like to make it stand out.
This is very important part of Groovy and it is kind of its hallmark.

1. Compile-time metaprogramming.

It means code generation during compile-time:

println "compile-time metaprogramming" // code generation during compile time

@Log
class Car2 {

    def regNumber
    def numberOfStarts = 0
    def weight = 2

    @NullCheck
    Car2(regNumber) {
        this.regNumber = regNumber
    }

    def start() {
        numberOfStarts++
        log.info "log: running"
    }

    def stop() {
        log.info "log: stopping"
    }

    def getRegNumber() {
        return regNumber
    }

}

try {
    new Car2().start()
}
catch (error) {
    println "error was caught: ${error}"
}

new Car2("12345").start()

It is enough to decorate the class with @Log to get logging capabilities and with @NullCheck to make sure constructor parameter will not be null. So, there are no explicit null checks in the source code but only in the compiled code.

2. Runtime programming.

Intercepting, injecting and even synthesizing of methods can be done during Groovy runtime. This may be not so clear, so let me show you the example:

@Log
class Car3 {

    def regNumber
    def numberOfStarts = 0
    def weight = 2

    @NullCheck
    Car3(regNumber) {
        this.regNumber = regNumber
    }

    def start() {
        numberOfStarts++
        log.info "log: running"
    }

    def stop() {
        log.info "log: stopping"
    }

    def getRegNumber() {
        return regNumber
    }

    def methodMissing(String name, args) {
        log.info "log: called missing method: ${name} with arguments: ${args}"
    }

}


def car3 = new Car3("12345")
car3.someUnexistingMethod("with parameter")
car3.metaClass.additionalMethod = { param ->
    log.info "log: called added method: additionalMethod with parameter: ${param}"
}
car3.additionalMethod("paramValue")

After special built-in method methodMissing is implemented, it will be called when unexisting method of the class is used. Also, additionalMethod can be added to the class and used in the runtime successfully.
Why to use such a feature at all you could ask? It is very useful when testing and when mocks are needed. I wrote related article in the past: mocking-with-groovy
It can also be used to more advanced tasks like writing testing frameworks.
I created one for Jenkins some time ago and so you may see the simplified version in Github as well: Jenkinson

Summary

These were very simple examples of various ways you can write code in Groovy. I really just touched the areas here but I did not want to make this post very long. I chose such examples as I personally used all these programming paradigms to some extent. There is obvious source of very detailed information there:
GROOVY-DOC.
If you have never seen the doc it is definitely worth it as there are tons of other language features to be used which I didn't mention here.
In my opinion, this flexibility is the Groovy advantage when considering the language for some task or project but also it is great feature when teaching someone to program.
I hope you learned something new about Groovy.

The future

grzegorzgrzegorz — Sun, 30 Nov 2025 16:32:26 +0000

I recently attended GOTO conference in Copenhagen (https://gotocph.com/2025, you can find the slides for some of the presentations there) and would like to share some of the interesting topics. This topic is going to be the last one.

The talk about the future by Kevlin Henney and James Lewis

The presenters shared very interesting story about the future we planned and the future we are going to have. Here are the main points and my comments as well.

The future was meant to be for everyone, but we landed in the place where it is actually for the few with unevenly distributed resources - yes, one can look at UNICEF report (https://data.unicef.org/resources/sofi-2025/) to see that 8.3 percent of global population faced hunger in 2024. The food is the basic need of the human and it is somehow not possible to provide it for the acceptable rate which should be like 99,9 % of the population.
The future tends to bring more infrastructure and information networks so that everything and everyone become more connected - I agree, we can see this is happening: we are connecting with the people using various social networks, we can travel quickly all over the world. The companies create customer experience which bases on all the online and possibly offline activities to be so close as virtual friend or maybe closer. They are able to gather huge amount of data and turn it into large income.
I am just not sure if this is the right direction, do we really want to be more connected with people and the business? Did anyone ask? I am sceptical, I can think of the scenario that we are heading towards digital crowd where everyone is just too close to each other.
We should still however have hope and excitement looking into it - Yes we should, I especially like the Mars colonisation idea. It seems it doesn't have much sense, it is extremly hard, but because of this it is exciting for sure.
The change is more late, gradual and cumulative than we think - These are tips on how to think about the future in general. We can use them when trying to foresee the evolution of quantum computing, genes edition, internet of things or other future technologies mentioned for example here: https://www.sciencenewstoday.org/the-future-of-technology-what-will-the-next-decade-bring.

As I see it, in my environment, there is not enough discussion about the future. I rarely can read anything in the news, I know that nobody teaches about it in the schools. We as the society are living in the past and only sometimes plan for the very near future. The Status Quo is the king.
The only exceptions are literature and movies but I feel like it is not taken seriously by the people, it is just the entertainment. I am sure we should be more aware about the processes which take place around us nowadays and plan more for the distant future as well to know at least the general direction we would like to follow.

Sonic-PI

grzegorzgrzegorz — Fri, 14 Nov 2025 16:55:06 +0000

I recently attended GOTO conference in Copenhagen (https://gotocph.com/2025, you can find the slides for some of the presentations there) and would like to share some of the interesting topics.

This was something very new to me to here about. Sonic-PI is the application which is crazy marriage of coding and art which also serves educational purposes. This was created by Sam Aaron. Not only was he talking about the technical details but he also gave a short performance on the stage playing various music by executing the code live...

He is very positive person with much energy and by this software he brings the example you can be coding not only for business. I had a chance to talk with him for a while and I very much like and support this idea. I think it is great it's possible to make a step towards art from technical IT world and create something so unusual. For me it is a new angle I can look at the music creation and performance.

I said this was the tool for music but it is also actively used for teaching programming. Children want to emit sounds and so they need to learn the syntax - the melody verifies if the code is correct. This is very encouraging for the kids to try new code blocks to achieve new musical results and so they can improve their coding skills fast.

You need to try it yourself and especially your children if they want to learn coding and create some nice music at the same time: https://sonic-pi.net

Sam is currently also working on another version of the idea to have coding platform for music and visuals using Erlang stack. This is work in progress yet but the results will be very inspiring I am sure.

Architectural decisions

grzegorzgrzegorz — Tue, 11 Nov 2025 17:45:11 +0000

I recently attended GOTO conference in Copenhagen (https://gotocph.com/2025, you can find the slides for some of the presentations there) and would like to share some of the interesting topics.

Problems which stem from architecture are still there. Decisions related to architecture are hard to make and hard to change while most often they need to be made before we know all the context. I attended quite a few talks related to this topic but I think Daniel Terhorst-North brings especially useful summary to tackle the problem:

keep things simple as "complex system can only evolve from working simple one" (paraphrased John Galls' statement)
avoid speculative generality, do not guess to be able to create some generic components - this comes from Donald Knuth's sentence "premature optimization is the root of all evil (97%)" and it just means we should not over-engineer
do not miss a chance to optimize critical parts - this comes from the 2. part of Donald Knuth's sentence "Yet we should not pass up our opportunities in that critical 3 %" - we should not under-engineer as well
learn to sketch - sketching is different skill than developing and it allows to create good prototypes which potentially can even be released (to me, it has much in common with vertical slicing technique)

I personally think that all above points are related to all the aspects of IT industry, not only architecture. "Premature optimization" statement was originally about the code performance but in my view, besides architecture, together with other concepts it also concerns quality (tests), devops and others.

MCP standard

grzegorzgrzegorz — Sun, 02 Nov 2025 16:29:18 +0000

I recently attended GOTO conference in Copenhagen (https://gotocph.com/2025, you can find the slides for some of the presentations there) and would like to share some of the interesting topics.

AI agents and Model Context Protocol

Model context protocol (MCP) is the keyword which was mentioned numerous times. It is trending term nowadays. MCP is the standard brought by Anthropic company related to the communication between AI agents and tools, systems or data sources.
MCP is the driver of the significant trend to let LLM interact with your private resources. The example scenario is that you use local AI agent (like Claude) to ask for a task like "help me reply to this email from my inbox". It works like this: Claude is creating MCP client which connects to MCP server (which should be running on your machine locally) which can read your emails. Claude sends both your request and the information about ability to read emails to remote LLM which in turn is asking Claude for providing the email message in question. Claude retrieves the mail content from MCP server and sends it to LLM which can then generate the right mail response.
Very nice explanation is here:
https://medium.com/@jamestang/deep-dive-understanding-mcp-client-server-communication-with-agent-and-llm-aa4782a65991
I must say I personally didn't try it yet. Maybe I will in the future.
I think about it as about AI in general: this is both a chance and the danger. The chance if we use it wisely: don't take the LLM output as the only source of truth. Give very specific tasks to do. Understand what you get and verify it before proceeding. However it is a danger when you forget to narrow down the context, ask for a too general task to be done or simply miss the hallucination produced. You can end up with so called workslop, useless outcome which only pretends the desired result.
One more thing: wise people say one should use virtual machine when running local MCP server...

Good people or bad people ?

grzegorzgrzegorz — Thu, 23 Oct 2025 14:03:27 +0000

I recently attended GOTO conference in Copenhagen (https://gotocph.com/2025, you can find the slides for some of the presentations there) and would like to share some of the interesting topics.

Kent Beck's "Forest vs desert"

This is about organisations, but I think it has even wider application. There are 2 types of organisations which differ only by the answer to the question: are people bad or good?
After the answer is provided, everything else stems out of it. If people are bad, you need to put the pressure, you need to control and make predictions. You are rigorous.
If people are good, they have the purpose, the community and the constant change which everybody deals with on daily basis. There is no need to take any restrictive measures.

These 2 approaches can be seen in my opinion everywhere when there is a group of people which need to follow any rules. This can be for example how the city authorities deal with passengers as far as transportation is concerned.
In London there is an assumption people are not going to pay, so there are physical gates in the subway stations. However in Copenhagen, there are no gates. You can enter the subway (which is automatic and doesn't have any driver by the way!) freely, that is without any barriers. The assumption is people buy tickets. This is fundamental difference which enables completely different atmosphere when travelling in these cities. I believe it works the same with companies.

However, the forest is rare. There are also quite many desert people who like the yellow color and in fact most of the organisations are like Sahara. I think the key is just to realize these 2 landscapes exist and know which one suites you best to be able to work effectively.
You can read more about the concept here:
https://tidyfirst.substack.com/p/forest-and-desert
https://martinfowler.com/bliki/ForestAndDesert.html

It is all about politics

grzegorzgrzegorz — Mon, 21 Jul 2025 21:45:00 +0000

Imagine the company which is delivering water from point A to B. This is their business value and customers are paying for this huge amount of money. You are coming there as a new hire and notice they are using buckets. They pile them up for few months: fill them with water and put them on the huge trolley truck. At some point of time they move it by hands to point B. All the buckets are constantly leaking. Strange thing.
Soon, some meeting starts, it is time for you to act.
"Hey guys your buckets are leaking!", you are so proud you can immediately contribute, "let's seal them up and then maybe we could think of some more automatic way of moving them between the points". Yes, it was easy, they are lucky they hired you.
You spot bored faces of the people, some of them are smiling. This tall guy always speaks up, no matter what is the topic. Yes, he is not going to let you down:
"Well, we are doing our business the right way. Of course, there is always a room for improvement but we are in the middle of delivery these days. We don't have time for anything apart from refilling the buckets and pushing the trolley".
"I understand, but this is far away from industry standards. Do you know that industry is measuring things like the time of delivering single bucket with water, how often is the delivery coming, how often water doesn't meet the quality standard and how fast you can stop the spoiled delivery?". Leaking buckets are strange but this seems to be even more weird.
"We have different specifics here, you see. We are delivering every few months", senior manager starts to explain, "also, we are not responsible for buckets as we get them from other team. If you want to talk about buckets you need to communicate with them. As you know we are already late with the delivery and have no time for theoretical discussion. The water quality team is probing the water from all the buckets - do you imagine how many of them we have? It is a huge work. We need to refill if something is wrong and just after they finish, we push everything to point B". This starts to sound consistent in some twisted way.
"Ok, the delivery is so important. Maybe we can put some oil to the bearings? It would make the pushing action lighter? Quick action with some immediate effect, what you say?", you try to play their game.
"That is a great idea. Just please contact the team who is doing oilling stuff as you have no privilege to do it alone", senior manager explains politely but it seems he starts to look little bit annoyed.
It feels at this point like you are from different planets.
"Why don't we have team responsible specifically for delivering buckets with water? There are separate, functional teams here and you have to wait forever for every small single action needed to make the delivery as there are teams responsible for details but none of them for the business value!". You know you said too much but you feel helpless. No people are smiling now and almost everybody looks nervous.
"This is my last answer. I am sorry, we cannot let you undermine our work", senior manager is very professional, "we may have some slowdowns and other imperfect things but we are not responsible for teams. You have to talk to someone else about it. Meanwhile, let's get back to water quality."

It is the real life example of how badly company can act. More important however is the question: why is it not possible to fix the buckets not to mention any other more important improvement? The answer is because it is all about politics. Without the ability to persuade people and unite them under the idea, it is not possible to bring it to life. It doesn't matter if the idea is stupid or extremely useful for company: status quo can only be changed when you have the majority which supports your idea. You need to approach persons individually and only after they are on your side you can try to start the topic officially. If you are not good politician, the buckets will always leak.
If you are CEO, VP or the owner of the company you have the power to change things alone, but didn't you have to be a good politician to get to this point anyway ?

APPENDIX:
I recently heard conference speech where I learned that to break the status quo one can try to speak managers' language, addressing risk and cost of the project as well as manager's status. It seems your chances are high when you say: "I have the idea which will save us around 20% of the money we spend for each release and which doesn't bring any risk. I think our VP could be glad, I remember he was complaining about the rising expenditures on the recent all-hands meeting."
You should then hear: "O, really? Can you give me some details?"

For sure, the bigger the organisation is the harder it is to break the status quo.

Mocking with Groovy

grzegorzgrzegorz — Sun, 14 Apr 2024 17:14:31 +0000

I would like to share some nice feature I am using extensively to test Groovy code. I am going to make this post short and hopefully useful.

Mocking in Groovy

There are tons of possiblities to mock in Groovy: groovy metaprogramming. Groovy metaprogramming is one of the features which stands out for sure. We are talking about runtime and compile time one. There are others features like: ability to use static and dynamic types, ability to use functional and oo paradigm and also almost full Java compatiblity so you can write in Java if you need for some reason. Groovy is JVM language, so it works wherever JVM works: if you never tried you should at least take a look. It's been years I have been using it and I am still impressed. Ok, I really want to make it short...

StubFor/MockFor example

So, to selectively mock a method it seems one of the most popular way to do it (aside ExpandoMetaClass) is to use mockFor/stubFor classes.
Given is the class under test:

class ClassUnderTest {

    def start(){
        println "starting"
        inner()
    }

    def inner(){
        return "original start message"
    }

    def stop(){
        println "stopping"
        return "original stop message"
    }
}

When inner method is to be mocked to return modified return value, we can try to test it like this:

void "test: stubFor use"() {
        given:
        def stub = new StubFor(ClassUnderTest)
        stub.demand.with {
            inner{ return "mocked start" }
        }
        stub.ignore("start")
        stub.ignore("stop")
        when:
        stub.use {
            def classUnderTest = new ClassUnderTest()
            def startResult = classUnderTest.start()
            def stopResult = classUnderTest.stop()
            then:
            assert startResult == "mocked start"
            assert stopResult == "original stop message"
        }
    }

And... it doesn't work. I put inner method on purpose in ClassUnderTest as it cannot be mocked in this way. The above test fails:

Assertion failed: 

assert startResult == "mocked start"
       |           |
       |           false
       'original start message'

It happens so as when ignoring specific method, all underlying calls seem to be ignored as well. I stumbled upon this so many times I needed another solution.

ProxyMetaClass

ProxyMetaClass extends MetaClassImpl so it is a sibling for ExpandoMetaClass. I put the link for Expando but not for ProxyMetaClass as for some reason there is no decent documentation for it.
Anyway, it turns out this is very handy way for mocking things in Groovy, which works as needed:

void "test: ProxyMetaClass use"() {
        given:
        ProxyMetaClass clsUnderTestSpy = ProxyMetaClass.getInstance(ClassUnderTest)
        clsUnderTestSpy.interceptor = new GroovySpy([inner: "mocked start"])
        when:
        clsUnderTestSpy.use {
            def classUnderTest = new ClassUnderTest()
            def startResult = classUnderTest.start()
            def stopResult = classUnderTest.stop()
            then:
            assert startResult == "mocked start"
            assert stopResult == "original stop message"
        }
    }

With GroovySpy class:

class GroovySpy implements Interceptor {

    Map mockMap = [:]
    boolean invokeMethod = true

    GroovySpy(map) {
        mockMap = map
    }

    Object beforeInvoke(Object obj, String methodName, Object[] args) {
        if (mockMap.any { entry -> entry.key == methodName }) {
            invokeMethod = false // do not invoke if method is mocked
        }
    }

    boolean doInvoke() {
        return invokeMethod
    }

    Object afterInvoke(Object obj, String methodName, Object[] args, Object res) {
        invokeMethod = true // restore variable value
        if (mockMap.any { entry -> entry.key == methodName }) {
            return mockMap[methodName] // return mocked value
        }
        return res // or return original result if method is not mocked
    }
}

We can provide multiple methods in a map and they will be mocked while the others will be run as originals.

There is huge amount of information about ExpandoMetaClass around so I do not put anything related here. Also, I authored Jenkins testing framework where I extensively use ExpandoMetaClass to mock everything in pipeline file (which is beyond default Groovy syntax) so you could take a look as well: Jenkinson

Summary

Groovy is extremely flexible and handy in most of the situations. ProxyMetaClass is great way for mocking but lacks documentation or even useful examples that is why I think above information should be useful one. At least it helped me a lot in my tasks.

Year summary - books I recommend

grzegorzgrzegorz — Sat, 06 Jan 2024 17:07:09 +0000

Year summary

It is good time these days for year summary. I would like to recommend books which I read in 2023 and which I believe
made me better engineer. I had more books in my hands but these one I find to be most valuable from my point of view.

"Five lines of code" by Christian Clausen

Book link
This is great book about refactoring. Very clear tips on how to start and where to go with the refactoring process. I think the most
valuable for me are simple tips like: "do not use switch statement", "do not use abstract classes" and my favourite "avoid inheritance".
All this tips are coming with TypeScript code showing the practical appliance of the refactoring rules. Actually, as a side effect, I got interested in TypeScript after reading this book. I very much like cognitive constraints described which are related to every human and the way they affect our code understanding.
In the past I often had troubles with understanding the code which spread across many classes like with 4-level of inheritance. Now I know this is not my low level of expertise but badly written code.

"Effective software testing" by Mauricio Aniche

Book link
Systematic testing approach here. One can use this book as checklist of which test design techniques to use and in which order. This dismisses the uncertainity we often have when dealing with new testing problem. Requirement based testing, structural testing, contract based testing explained.
New thing for me was properties based testing which is part of this book as well. I was somehow not aware about this kind of approach before.
I very much like and agree with author encouraging to be systematic in this area.

"Functional thinking" by Neal Ford

Book link
Functional programming doesn't seem to be common these days. At least not for everyone just as it was not familiar to myself. I found out about about the set of basic functions which are there in all languages which support functional programming: filter, map and reduce. Currying and memoization as well as optimization which
is there behind built-in functions is explained. Author is supporter of applying specific programming paradigm in certain areas which I find very useful and which I often see in other books: write functional code in the core of your application and be more imperative (oo) when going to the edge of the system (controllers, UI).
This turned out to be very important book for me: I started to think about functions as something aside of object oriented programming and I use them conciously since then.
Finally, I know what I exactly have in my functional toolbox and when to lean towards functional paradigm.

"Code that fits in your head" by Mark Seemann

Book link
This book is the most recent one on my virtual bookshelf. It turned out to be kind of summary of all 3 previous ones.
It talks about cognitive constraints, proper testing approach and it also mentions functional paradigm when coding the core of the application.
However, it has additional advantage, at least for me. Author has the ability of expressing his thoughts in very clear way and so it is like listening to the expert in the office at his desk, getting answers on how to deal with specific problems properly.
The are numerous of them addressed there: how to start application from the scratch, when to send feature branch to review, what to write in commit message, how to write the class, method so that it is clear. I very much like fractal architecture proposed by the author.
Also, teamwork aspects like code reviews are mentioned. There is great piece of information about human short term and long term memory and how does it affect our code understanding. All of these aspects are explained basing on the code of restaurant application.
This is most important book I read last year and so I very much recommend it.

What next?

I am now looking more towards devops related stuff, I plan to take a look at very much recommended "The DevOps Handbook" by Gene Kim and others. However, maybe some of you also have recommendations of important sources of information from IT area?

Finding time for self development

grzegorzgrzegorz — Sun, 03 Sep 2023 15:42:32 +0000

Intro

We have so little time when we are working. Projects, deadlines, meetings, sometimes business trips, commuting. Family life also requires much time especially when there are small children, not to mention everyday home related tasks. We need some sleep maybe as well? This is all good of course.

The problem

I assume many people would like to also spend some time doing things which are not directly related to their tasks in the company, but which are related to their interests and will allow them to improve their skills - technical or non-technical ones - to better do things they are passionate about. This might be some pet project or open source project or maybe just reading things (books, blogs), listening to podcasts to learn new things.
Anyway, I personally need spare time for such activities and I many times hit the problem of the day being too short.

My solution

There are 2 things which work for me.

The first one is when I read something interesting with the intention to learn it. As I do not need long uninterrupted time for this, I can use free minutes which are always there during the day: commuting by public transport, waiting at the doctor, waiting for kids at the school etc. Reading in the night doesn't work for me as I am tired: only fun facts at this time!
Technically, I do not use laptop nor smartphone for reading. I need to make notes, do some highlighting, be able to quickly navigate through pages and most importantly be able to see the text in the middle of the sunny day. Luckily, last year I discovered something which is called e-ink tablet and which significantly boosted my learning capability. I just export everything as epub or pdf and send to the device.

There is second type of tasks I do which requires uninterrupted period of time with laptop in front of me. Like writing this article or doing my pet project. For this purpose, I use Eisenhower matrix approach. As you can see, there are 4 quadrants there. Something which is A: important and urgent, B: important/not urgent, C: urgent/not important, and D: not important/not urgent.
A is often related to our personal life or duties at work. We need to do it immediately or at least start it. Similarily, C is there as well but this is enough to delegate (if there is anyone we can delegate to, of course). Let's try to always recognize and skip D things. What is the difference between urgent and important you may ask? This is about what happens if we ignore them. Undone urgent tasks imply unpleasant consequences that may show up very soon and undone important tasks undermine long term goals. Do urgent things to avoid consequences and do important things to make long term achievements. This is exactly where self development is located. We want to improve our skills in long term. It is B so it needs to be scheduled.
This is exactly what I do: when few free hours in some coming workday seem to show up or there is going to rain all the time during the nearest weekend I schedule few hours to work for myself. It doesn't happen often but at least I am able to do it frequently.

Summary

This way or another we need to find spare time for self development if we like what we do, if we want to be better at what we do. Because of the limited number of hours during the day we should have some concious approach for this.
What is yours?

Skipping tests is good

grzegorzgrzegorz — Tue, 11 Jul 2023 21:41:55 +0000

The problem with tests

Recently I had problem with personal job in the pipeline which was designed to build and run all the unit tests and integration/heavier tests after. The idea seemed to be perfect - run all the tests on every change developer does when working in feature branch.

The reality quickly verified the idea: job duration was initially around 30 minutes, slowly but steadily growing to 60 minutes. Let's wait for an hour for simple change to be tested...
The content of each feature branch are extra tests as well so their number is growing constantly. What will happen in few months?
2 hours, 3 hours of waiting?

Important thing: application under test is 100+ modules monster with more than 10 top level ones. The bigger monster, the faster it grows.

The quickfix

I came up with idea to test only area each commit is changing. So if there is a change in moduleA, unit tests related only to moduleA and its direct dependencies are run. Also, only integrations tests related to this module directly come to play. (It turned out I have to skip indirectly dependent integration tests as all of them were run even for single module changes most of the time).
The result was really good: for changes in some modules which do not have many dependencies the duration was cut to 20 minutes. Building, testing and integration - great !

The final solution which I didn't do yet but I think I should

It is important to keep valuable tests only and delete the trash tests (what is the valuable test is the big topic for separate post for sure). One should also be suspicious if number of tests is growing quickly. It is a sign the process of creating them is wrong, like some kind of aggressive and fanatic TDD. If no action is taken, they will very soon spoil development by slowing it down first and then bring it to the complete standstill. The monster will eat all your resources. But that's easy stuff: persuade fanatic TDDevelopers they should stop...

I think main pipeline should also test only commit related areas and not "everything". The fear of missing the right coverage is huge however and in reality I know, managers prefer to slow down feature delivery than to rely on smaller subset of tests. Just persuade fearful managers now...

The goal of this text is more to share experience and ideas with you than to announce ex cathedra golden rules and shooting silver bullets.
That is why I am very much interested what you think about it.