My Writing and GenAI

I follow my plan of focusing on fewer tasks. This puts a lot of pressure on my time. In addition I spent almost every evening of the last months exploring GenAI. My wife got sick of me talking about agents, tokens and the like. Besides my feelings about the change of our industry I did not write much. Having little time and less practise in writing made writing more unlikely - a vicious cycle. I had no idea where putting my thoughts would end up. It might become a rant. (Sidebar 1)

Working With Text
What to look for? I use writing to structure my thoughts. This is rubber ducking, a practise of talking through a problem. In doing so, your brain structures the problem as part of communication. This often lets us find the solution to the problem. I learnt about this technique from The Pragmatic Programmers, a book I recommend since 2011. The idea itself is way older and based on Joseph Weizenbaum's ELIZA from 1966. (You can try ELIZA here.)

More than once the outcome of my writing was different than I had expected or planned. I partitioned and analysed the problem during writing and found better results. This is the benefit. I lose if AI writes the text for me. It will format my notes nicely and present something that looks reasonable but it will not end with opposing results. And even if it would, I would reject them because I am unprepared for opposing results. I need to go through the work of structure and analysis to find and accept a different outcome than I had anticipated. My writing needs to be slow and meandering and cumbersome.

When writing about technical topics, e.g. the latest Coding Fun, I have to structure the material linearly to make it possible to read for people who are unfamiliar with what I want to present. This makes me reflect on the topic from a distance, after I had been in the fine details all the time. This summary adds to my understanding of the material.

On LinkedIn is a group of people who claim that they put as much thought and effort into their AI generated articles - which would also mean they get the same benefits. I do not know, maybe they do. But Mathias Verraes disagrees. He claims to recognise AI-generated text because he read so much. The generated text contains the same cliches and seems to be uniform - for sure statistically averaged. These articles are boring which makes them unreadable. (Sidebar 2)

I do not write enough and miss practice. Getting started is difficult, collecting ideas takes time and I edit everything more than once. I guess Mathias will resent my writing. ;-) I struggle with articulation as English is not my first language. I could use GenAI to improve my articulation - it would keep my ideas and thoughts, at least according to the proponents of GenAI. But I reject it. I want to improve my articulation myself. Articulation is a skill, writing is a skill, and both need practise. (Sidebar 3)

I like writing by hand, or should I call it writing manually: I am creating something and showing the world. Using GenAI for my writing removes all these benefits: I am not structuring, expressing, and polishing my thoughts. I am not summarising known material. And I am not practising and improving my writing. Dylan Beattie phrased it in his GeeCON 2026 keynote: "If something is fun and you're learning - using AI brakes both."

What Makes A Person?
Another goal of my writing is to share my knowledge. Other than expressing myself, sharing is a marketing tool, at least part of developer branding. As GenAI disturbs my beloved coding, I need to rethink my business. What makes me successful since 15 years? Besides my technical expertise I believe I am successful because I am authentic. I teach what I know and have experience from past projects and always state up front when I have no clue. (Sidebar 4) I avoid marketing buzz words and stay away from promising anything. I demand perfection from others and even more from myself. I live what I preach. I have no idea what my clients buy when they hire me for the first time (when they do not know me yet). I believe they buy the promise of my reputation. All my work comes through personal recommendations. (Thank you so much my friends.) For sure a large part of my business depends on my contacts and personal, authentic connections. Being honest, admitting mistakes and taking responsibility for my actions are important to me. No generated text, regardless how well structured and nicely sounding, supports those.

Generated Correspondence
In the early days of Chat-GPT I ran an inhouse Coderetreat for one of my clients. A local organiser sent an invitation to all developers. Instead of writing one or two sentences about the upcoming event, he generated a full page of text about being "delighted" to host such a "spectacular" event and more exaggerated terms. This is a common problem. Me friend Raimo writes about interacting with coworkers talking to us only through parrots which makes him frustrated or angry at times. I fail to understand why people would do that. (Sidebar 5) Particular in an corporate environment, nobody cares for style or typos in work emails. As time is money, long emails and chat messages are discouraged. The respect for our coworkers' time should stop us from creating (large amounts of) useless text. Please never send me AI generated text. I will never use AI for mails or personal messages.

I am a geek, spending my evenings alone, in a dark room filled with hardware and pizza boxes - at least kind of. And at the same time I like working with people. I value human connection. It makes much of my work meaningful and worthwhile. Human beings are social, everybody needs human connection somehow. To connect I need to express my feelings (like about accepting GenAI) and I want to be seen. AI is unable to express my feelings and it certainly can not make me seen. Connection is not happening if I do not expose myself.

My AI Writing Manifesto
After collecting notes and thoughts since May this year, structuring my thoughts and polishing then, I found clarity:

• I structure and formulate my thoughts and ideas myself. AI does not support me in digesting and distilling content.
• I summarise technical expertise myself. AI does not support me in finding deeper relations based on known material.
• I author and polish my writing myself. AI does not support me in practising and improving my writing skill.
• I keep a honest and authentic relation to my clients and peers. AI is neither.
• I respect your time and keep all messages short. AI generates bloat.
• I write all messages myself to express my feelings and to be seen. AI hides me.
• All images I use are real images, unless marked as AI generated.

---

Footer
I was massively distracted while writing. I kept finding notes from the last five months on different aspects of this. The topic had been on my mind for some time. After finishing the outline I streamlined the text and moved my secondary thoughts into this section. While off-topic these thoughts were reasonable - I might expand on them later.

1) Blog Rants: I have not written any rant since I went independent. This is a good thing. I do not miss the corporate politics and hidden agendas.

2) Hate of Generated Text: In my social "bubble", there is a crusade against AI generated text. I can relate. The massive creation of AI slop is speeding up the Enshittification of the Internet. For example: This January I suffered from pneumonia. Staying in bed I searched the web for articles comparing AC generators. I planned to buy one powering tools in the garden. The web search showed promising results. But each page turned out to contain generated text of products with deep links into Amazon, and no real descriptions nor any comparison. Maybe due my weakened state, I was devastated. I recognised that the Internet was broken. That was not the web I had learnt to trust for its usefulness.

3) Practice and Mastery: I am a big fan of deliberate practise. I practice deliberately since many years and have talked about it in the past. I use that approach for all areas which I care for and where I want to improve. I want to achieve mastery (as a path not a state). Maybe this is folly: I am in a position of privilege which allows me to reflect on my skills and put aside time to practise, which is like play, unproductive. I am able to laugh about failed attempts and try again. I like the experience of the flow you get after reaching a certain level of skill. Having invested huge amounts of time into practise makes me respect the effort and skills of other people. Coming back to AI writing - I am unable to respect neither the author nor the work using AI because there is little effort and skill required.

4) Working with technologies I do not know is an interesting situation as a coach. I always confess in the first meeting with the client when I have no experience with certain technologies they are using. 12 years ago, I worked with a company using PHP. Back then, they used PHP 5, which had a bad reputation. I had never seen any PHP before. I struggled a lot with its dereference operator -> and always used the more common . instead. When pair programming I always mistyped it and one of my pairing partners designed a T-shirt for me saying "this -> is not this .". In the end I knew more about PHP than most developers I paired with because I knew what to expect from a language and how to google it. Another time I worked with C# which I had never touched before. That was even easier, as at the time, C# was "Java in Pascal case". ;-) After learning some programming languages, at least the main stream ones, all languages look the same.

5) Why generate bloated text? I am wondering which universal human need is met when people generate work emails with GenAI, making them many times larger than necessary. It is not efficiency, as the prompt takes longer than the pure message. It is not reputation, as everybody recognises the generated text. (Ha ha sequences of "it is not" are a sign of AI generated text. Fear not dear reader, I am able to author bad writing without any AI any day. ;-) People generate content for Wikipedia - which is vandalism and go on when asked about it. Which need is met by these actions? I will have to investigate. The best I know is "because I can" which is self-efficacy, an important need indeed.

Y U NO TDD

During this year's GeeCON the crew organised an Open Space evening. (An Open Space is a self-organising meeting where the agenda is created by the people attending.) I participated and ran a session on the question why we are not doing Test Driven Development. (Y U No Do TDD?) I am running TDD trainings from time to time and wanted to get more insight where people are stuck with TDD.

Context
As I said, an Open Space is self organising, and only people interested in TDD attended my session. This is a typical problem of communities of practice - only people interested in the topic attend - which results in us living in a bubble. For example long time TDD practitioner Thomas Sundberg and Shirish Padalkar, lead consultant at ThoughtWorks, participated in the discussion. Depending on the background of each individual participant, my original question was understood as:

• Why are you not doing TDD on production work at all?
• Why are you not doing TDD most of the time?
• Why are you not doing TDD all the time?

I collected the reasons not to do TDD during the session which I want to share here. Text inside quotation marks, e.g. "hi" quotes exactly what people said. While the previous three questions are slightly different, the reasons seem to be similar. I grouped the answers. I did not want to contradict or debunk these answers and have to hold back not to do so ;-)

Prototyping
I am "experimenting with something", the "expected outcome is unclear" and "it's only a prototype". Obviously these are valid reasons as Spikes are outside of TDD. These answers usually coming up quickly makes me wonder if they are kind of excuses sometimes. Experimenting with new libraries and APIs is covered further down, so what are we experimenting with? I worked with many developers who would agree that the expected outcome of their current ticket was unclear - because they did not take the time to analyse the story and understand the solution they were supposed to build? Additionally most of our prototypes go to production after all, don't they ;-)

Time Pressure
Another reason - given by some of my clients too - is their need to go fast: "I need to go very fast", there is "no time for that" and I "believe to be faster without it". While they might be wrong in the long term I understand the effects of pressure. One person made it more explicit, while he has no strong deadline, he said "I have a huge backlog, I am stressed". Indeed when I am extremely stressed, I find it hard to maintain a structured approach, especially if a lot of task switching is involved. Besides the needed skill to apply TDD under high load, much discipline is required to endure pressure. In such situations Strong Opinions and Dogma might help.

Missing the Bigger Picture
I am just "writing a script for myself". Maybe there is no need for automated tests when writing a one time script for myself. TDD has a testing aspect - and it has many other aspects like designing software, fast feedback and working incrementally. TDD is not only about testing. Some people miss that or have only partial understanding of the benefits or do not care for these benefits at the moment. The opposite reason is "because I know how the class will look like". Yes TDD is about software design as I said before, and I would like my class to work, too. Some people only want the fast feedback, e.g. using REPL based development and "looking at UI is faster".

Missing Priority on Testing
When starting with TDD, the testing aspect is most visible. After all we have to write a reasonable test first. For teams and organisations with low or missing priority on testing, people are "looking down on testing" and I got answers like "testing is a culture thing", "testing is not a first class activity" and "I am not asked to create a test by my project manager". Indeed it is hard to keep following TDD if it is looked down upon and if there is no time for quality work.

Avoiding Context Switches
There is a certain amount of context switching involved in TDD. Similar to Edward de Bono's Six Thinking Hats, we have different states which we have to be mindful of and which call for different actions. George Dinwiddie created a TDD Hat to show that. Maybe this switching is "not natural for some people". "I don't want to interrupt creative design with verification" and "I prefer staying in building hat and not change to testing hat". Similar one participant said that it is "easy to write code, harder to write tests, so I do it afterwards". I understand and there is certainly an urge to jump into the code and get hacking. I rarely feel that urge and I enjoy pair programming using the Ping Pong style because it enforces the separation of states without any (inner) discussion.

Missing TDD Skills
This is obviously the largest area and there is nothing wrong with not knowing how to apply Test Driven Development: Honest people just say "I can't do it". Many are aware of this problem and seem to be disappointed with existing material and/or look for more material to study TDD: "It is not taught at universities", "there are no good books" and "I am missing real examples". I know from my own experience that TDD is not easy to learn and some people are "scared for life after a bad experience" with it. Now the best way to learn TDD is to have someone show you while pairing with you. Even if there is no pair programming in your workplace, you can still experience it during a Coding Dojo or Coderetreat. Short of that, I recommend Kent's Beck Test Driven Development by Example, which is a short and excellent introduction.

New Language or Library
When discussing TDD and unit testing with a client, he said I "don't know the target technology" and "React is a new technology for us". I had to laugh. To me this sounded like "I got a car and know how to drive forward, but am not able to drive backwards." On the other hand I live at the dead end of a road and I see drivers working really hard to avoid driving backwards. Are they not able to do it? So maybe stopping halfway in the game (of skill acquisition) is natural after all. When working with some new language or working with an unknown API, I specially rely on tests to support me, these are Learning Tests.

It's too hard to test
I agree some things are harder to test than others. "Android is hard to test", "Vaadin is hard to test" and "some libraries are hard to test". (I have not worked with Android or Vaadin, I quote people.) We might need to know more about design to decouple things. This is definitely true for legacy code, as "existing code is usually hard to test". Some people see the root cause, like in "I don't know how to manage boundaries". In such situations we need (to know) more tooling. We definitely "need more tooling to test the UI" as UI is traditionally considered hard to test from a TDD perspective. Still, Steve Freeman and Nat Pryce, authors of Growing Object-Oriented Software Guided by Tests, always start their TDD (outer) loop with an UI test. GOOS is a great book and I recommend reading it if you want to go deeper into TDD.

It's too simple to test
If there are things which are too hard to test, there must also be things which are too simple to test, right? It is "useless to test, it is so simple" and it "makes no sense to test it". Maybe a better description is that it is "unclear what is important to test". From a TDD perspective no such things exist and I guess these reasons arise from the test after process, when looking at each public method and thinking how to test it. Further excessive test isolation, see Solitary vs. Sociable Unit Tests, will cause that.

Barriers to TDD adoption
Here is Matt Wynne's summary of Barriers to TDD adoption from a session during Lean Agile Scotland 2016. I recommend checking out the Twitter thread as Matt added detail discussions on temptation of fast reward, permission and safety to learn, "the egotist" and other reasons not covered by me.


What about test-induced design damage?
Maybe the only real reason not to do TDD is to keep the design integrity of your system. This idea was started back in 2014 by David Heinemeier Hansson, also known as DHH, and led to the whole Is TDD Dead? debate. DHH said that when using TDD code sometimes suffers tremendous design damage to achieve two testing goals: Faster tests and easy-to-mock unit tested controllers and that the design integrity of the system is far more important than being able to test it any particular layer. It is ironic that this never comes up during any group discussion or team interview. Probably because it is an expert level reason. If you followed the debate, DHH knew TDD, he used it for some time and liked it. And then, only then, did he know when not to apply it.

Work Harder

With this article I want to prompt you to work hard(er). What does working hard mean? When I looked for different translations of German Strengt Euch an, I found several ones, which are all suitable: Work hard. Keep it tight. Push yourselves. Put some heart into it. Put some muscle in it. Put your backs to it. Make your best effort. Just play it like you fucking mean it. Obviously hard work needs your strength. It also needs your heart - motivation and dedication. It might test your limits, both physical and psychical ones.

My favourite example of hard work was writing books in the Dark Ages. Monks were copying books by hand, adding drawings and decorations as they went. An extreme example is the Codex Gigas, which was handwritten by a single, anonymous monk. Because the scribe was a monk he may only have been able to work for about three hours a day, and this means that the manuscript including decoration probably took at least 20 years to finish, and could even have taken 30. Now that is a whole lifetime for collecting and handwriting a single book. Imagine the dedication.

Maybe less extreme is the life of master craftspeople. Several years ago I wrote about a master craftsman hand-crafting rakes. He could retire any time, still chose to improve his methods and work hard all day.

Benefits of hard work
Most of you will agree, that hard work pays off. Here is a little TED talk by Richard St. John, who explains why it is so: Hard work is the real secret to success. I vividly remember a professor of Mathematical Analysis during my studies: At the beginning of a lecture he wrote a theorem on the blackboard, followed by an easy proof. The proof looked good and we students understood what was going on. Then he said "Was man leicht kriegt ist nichts wert" ("What you get easily is worth nothing"), pointed out a mistake in the proof and erased it. He used the remaining of the hour to sketch a valid proof which was complicated and much harder to follow.

Hard work has more value
Theodore Roosevelt even said that "Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty..." Maybe he was exaggerating, but a little pain never hurts. (Pun intended ;-) So is the motto in weightlifting training: No Pain, No Gain. Psychologist Katarina Veselko mentioned the topic in one of her talks. During the following conversation she explained: It not so much that we do not value things that are easy to get, it is more about the fact that when we need to invest a lot of energy, time, money, ... into achieving something, the result will be more valuable for us because we have invested a lot into it. It is some kind of Cognitive dissonance. She also believes that most things worth having are not easy to get; most things that are valuable to us are not achieved in a way that is always fun, fast and easy, but also includes obstacles and challenges.

Instant Gratification
The term Instant Gratification is often used to label the satisfactions gained by more impulsive behaviours: choosing now over tomorrow. And today it is harder to delay gratification than it used to be. We have been trained by technology and social media to expect results fast, without much effort. For example, there are more than 2 million hits on Google how to earn 5k extra, many of then offering "work from home, 30 minutes daily" up to "basically doing nothing". The same is true for losing weight without any diet and so on. If you want to read more on Instant Gratification and its problems, I recommend Courtney Ackerman's Definition with Examples.

Conclusion
It seems that working hard has become unpopular. Why work towards a long term goal when many things are handed over on a plate, or downloaded at the click of a button, or ours in twenty-four hours for just £9.99 extra? I do not think that life works like that. Why do I come up with this in my blog? I am writing this because I think we Craftspeople need to work harder. I am not talking about working more hours. In fact working overtime is against the idea of Craftsmanship because we need our free time to reflect, exchange and learn.

I am talking about pushing ourselves more: Following up on that refactoring you did not finish last week. Refactoring mercilessly, always pushing to keep the whole code base clean and consistent, even during architectural changes. I am talking about not accepting lesser standards because of low level, different or even obsolete technologies or environments. I am talking about overcoming pointless bureaucracy or managers who have no idea about code quality.


I know it is hard. Years of arguments with colleagues, fighting superiors, struggling to grow and working broken processes have taken their toll. Sometimes I feel old. But I have to defy them. Let us continue pushing, trying to work harder and make an effort!

Thoughts on Mastery

During summer time I was on vacation in Tyrol which is an excellent place for hiking. A local magazine told a story about Josef Frauenschuh and his business of hand-crafted rakes. Josef is a true master craftsman: He is of old age, many years past official retirement. He creates large wooden rakes of highest quality using different kinds of wood for each part of the rake. His rakes are balanced and lightweight. He uses the best tools he can get, all of them are self-made and after 45 years he is still improving his tools and process. Obviously he does not accept any compromise. Once, when he needed more space to create the shafts, he simply made a hole in the wall of his workshop.

I liked the story a lot. It made me think about our craft and the concept of mastery.

I believe that one major aspect of mastery is age. It is not necessary by itself but rather is a side effect of the time needed to master a subject. Masters are aged because they have been practising their craft for 30 years or more and still try to improve. Following this definition it is obvious that there can not be many masters of software development, because our industry is still young. Only a few like Uncle Bob are working in the industry long enough, whereas most of us have less than ten years of experience. The so-called senior developers with five years of experience are just young journeyman, if at all.

Josef is working hard. Although he could retire any time, he is working five days a week because the demand for his rakes is high. He is a master and his rakes are masterpieces, but does he get rich? I do not think so. Following the story I assume he has to put considerable effort into each rake, and sometimes the wood splinters and he has to start over. Being curious I compared the prices and his rakes sell for around 70 Euro, whereas eBay has some for ten to 20 Euro, although no wooden ones. So yes, the masterpiece is up to five times more expensive than a regular one.

Still it seems that Josef is not earning five times more per hour than other workers. Could it be that master craftsmen are relatively underpaid because they put in extra work to create magnificent things? Maybe his rakes are expensive to compensate for the small number he is able to produce. That does not compare well to our industry. We (developers) are greedy. We expect a good salary matching our experience and competence. The more experience we have, the more money we want, which seems only fair. The never ending demand for IT professionals spoils us and salaries rise during the first years of junior developers' careers. At least they rise up to a certain point, which might be 15 years of experience, when we become "too senior" for most employers. But this is another story.

I do not know Josef Frauenschuh but I believe him to be a true master craftsman. Instead of bragging about his achievements, he is modest and admits that sometimes he even has to listen to outsiders to improve his rakes. He does not need titles of seniority, nor is he proclaiming himself to be a master. I guess he considers himself still a simple carpenter. He is a great example. Some of his modesty would suite us software people well, and I will start with myself.