Konflikter er uundgåelige. Hvordan du håndterer dem er forskellen på tab og vækst.
Som selvledende medarbejder kan du træne dig selv i at kommunikere klart, respektfuldt og stå fast. Dermed bliver du bedre til at forhandle løn, arbejdsbetingelser og opgaver.
Som leder kan du træne dine medarbejdere til at kommunikere klart og respektfuldt og dermed skabe høj psykologisk tryghed. Dit team vil performe bedre, have færre konflikter og mindre sygefravær.
Som leder-konsulent kan du give virksomheder et sprog og værktøj til at løse konflikter og styrke samarbejde, som giver bedre resultater på bundlinjen.
Alt dette kan du opnå med Assertiveness Continuum (spektrum for selvsikkerhed):
Det er en model, der hjælper dig med at finde balancen mellem at være passiv og aggressiv.
Hvordan gør man?
Du vinder en luksusrejse. Uheldigvis falder den i samme uge, som din kollega skal til koncert. Kollegaen har bare ikke bedt om ferie endnu.
Her er nogle valgmuligheder, hvilken vælger du?
😶 Passiv Selvudslettelse: Glem rejsen. Din kollega kan nyde sin ferie og du slipper for konflikten.
😬 Passiv Manipulation: Spørg kollegaen. Måske vil den dårlige samvittighed lade dig vinde?
🔥 Aggresiv Offensiv: Kræv retten. Nedgør kollegaens behov, du skal på luksusrejse!
🔪 Aggresiv Baghold: Snup ferien bag om ryggen på kollegaen. Det handler om først til mølle!
🗣️ Assertiv: Udtryk dit behov på en respektfuld måde. Så kan I løse det som voksne. Og hvem ved, måske finder lederen plads til jer begge?
Hvis kollegaen reagerer umodent? Så forbliver du rolig, tydelig og fair, for din leder skal nok træffe et fornuftigt valg.
Er lederen også umoden? Hold fast i respektfuld kommunikation, for du bidrager til noget større og vi vokser alle af dette!
Hvad får du ud af det?
Assertiv kommunikation er ikke bare “pæn opførsel”, det er en kompetence, der skaber målbare resultater: bedre trivsel, bedre performance, færre fejl og lavere fravær.
Uanset om du er selvledende medarbejder, leder eller konsulent, starter forandringen én respektfuld samtale ad gangen.
🎯 Er du klar til at blive konflikt-klog? – Del gerne dine tanker i kommentarfeltet!
Forestil dig, at hvert strategisk valg, du træffer som leder eller som medarbejder, potentielt kan sende hele organisationen tilbage til startfeltet.
Det lyder ekstremt, men i en verden præget af uforudsigelige markeder, og teknologiske skift er “game over” aldrig langt væk.
Safe-to-fail-eksperimenter kan vende usikkerhed til innovation.
Det store spørgsmål er: Hvordan?
Hvordan bruger man safe-to-fail-eksperimenter?
Der findes et ældre computerspil der hedder NetHack.
I spillet har man et og kun et liv. Dvs. når man dør, så starter man helt forfra:
Man mister sine kræfter og udstyr.
Banerne blive lavet på ny, så man skal udforske dem igen.
Spillets regler ændrer sig også. I ét spil kan en rød drik være gift og en grøn drik helbredende. I det næste er det omvendt. Du kan altså ikke huske dig til succes – du er nødt til at lære forfra hver gang!
Kan man blive bedre i et spil, hvor reglerne hele tiden forandrer sig?
Ja! Men ikke ved at huske reglerne – men ved at lære hvordan man lærer dem.
🥉Niveau 1: Tager ingen chancer: Når en ny spiller prøver spillet, så er de bange for at blive forgiftet og drikker ingenting.
🥈Niveau 2: Impulsiv eksperimentering: Efter nogle spil finder spilleren ud af, at de er nødt til at bruge drikke for at komme længere i spillet. Så de drikker alle drikke i starten af spillet, for hvis de dør, så er det let at starte forfra.
🥇Niveau 3: Strategisk risikohåndtering: Når de har spillet tilstrækkeligt, så lærer de, at kaste drikke på monstrene først. Effekten på monstret afslører drikkens hemmelighed.
👉 Pointen? I stedet for at lære spillets regler, lærer man, hvordan man kan lære reglerne på en tryg og sikker måde. Dette er kernen i safe-to-fail-eksperimenter.
Tre eksempler på at tjene penge, samt skabe innovation og tryghed
🥉 Eksempel 1, Tag ingen chancer: En medarbejder begår en fejl, men tør ikke sige noget – for hvem har lyst til at spille russisk roulette med sin stilling? Fejlen ender med at koste virksomheden 100.000 kr og skader omdømmet.
🥈Eksempel 2, Impulsiv eksperimentering: Medarbejderen forsøger hurtigt selv at rette fejlen uden at informere nogen. Nogle gange virker det; men ikke altid. Resultatet er igen 100.000 kr i tab plus skader på omdømmet.
🥇 Eksempel 3, Strategisk risikohåndtering: Fejlen bliver delt med leder og teamet. Det fører til en procesændring, der forhindrer gentagelser. Virksomheden sparer 350.000 kr i næste kvartal. Fejl bliver til innovation!
Hvordan kan du bruge dette?
Som en medarbejder kan du vise tillid til din leder og virksomhed. Penge der bliver sparret kan bruges til noget mere fornuftigt – som f.eks. din lønforhøjelse eller personale goder. Og samtidig kan lederen og virksomheden vise dig mere tryghed og tillid i din hverdag.
Som leder kan du hjælpe dit team ved at skabe tryghed, tillid, samtidig kan du spare virksomheden penge. Du vil kunne bruge fejl, som potentiale innovative business cases. Så har du altid råd til at innovere!
Som en leder-konsulent, kan du altid spørge en virksomhed, hvor meget en fejl koster. Kan du starte et pilotprojekt, hvor du kan forhindre eller minimere fejlen, så kan du få en bid af kagen. Win-win for alle!
Hvilke risici og muligheder ser du? Del gerne som en kommentar!
For at kunne lede sig selv og andre, skal man kunne navigere i forskellige miljøer.
Cynefin Framework beskriver 4 forskellige slags miljøer, som kan hjælpe enormt med dette:
Det er Klart, Kompliceret, Komplekst og Kaotisk.
Hvordan navigerer man så hurtigt og let i det? Især i Komplekst og Kaos?
Et sejle eksempel
Skal vi planlægge på forhånd som i vandfaldsmodellen, så svarer det til at vi kun må sætte start-retningen.
Når der er ingen vind (eller vandstrøm):
Så er det klart: Vi sætter en retning mod vores mål og vi når det.
Når der er lidt vind:
Så er det lidt kompliceret, fordi vinden bøjer vores kurs. Vi kan dog let kompensere for vinden med lidt matematik og korrektion af startretning.
Når der er flere vinde:
Her bliver det komplekst, fordi vi må først måle alle vinde ved hjælp af små test både. Vi lader de små både sejle ud og derefter kan vi finde vores start retning!
Når vinden skifter hele tiden:
Her bliver det kaotisk og uanset, hvilken startretning vi tager, så vil vi med høj sikkerhed ikke nå i mål. Selv hvis vi tager den samme startretning 2 gange, så vil vi ikke engang sejle det samme sted hen.
Her må vi lære og selv bedre at kende, således at vi kan løbende opdatere vores forståelse. Dvs. at kontinuerligt måle vinden og korrigere vores kurs.
Kort sagt: Vi må opgive vandfaldsmodellen og overgive os til Agile.
Uanset hvilken startretning vi så tager, så vil vi med høj sandsynlighed altid ende i vores mål.
Uhåndterbar kaos og håndterbar kaos
✔️ Kan vi skifte kurs hurtigere end vinden skifter, så kan vi udnytte vinden.
❌ Skifter vinden hurtigere, end vi kan skifte kurs, så kan vi ikke udnytte vinden.
Det handler om at kunne omstille sig hurtigere, end at miljøet forandrer sig.
Øger vi vores hastighed til at lære, så kan vi også håndtere mere og mere kaos.
Skal vi lege en leg?
Find 5 situationer i dit arbejde, som matcher hver kategori:
Klart
Kompliceret
Komplekst
Kaos
4.1. Uhåndterbart
4.2. Håndterbart
Eksempler fra en IT-afdeling:
Klart: En ny medarbejder skal have adgang til WiFi.
Kompliceret: Jeg skal finde en funktion i Excel, som jeg kan spørge Google om.
Komplekst: Vi skal lave en visuel graf over noget data. Ingen ved, hvordan vi gør det bedst og skal lave nogle prototyper først.
Kaos: Et større IT-system bryder sammen.
4.1. Uhåndterbart: IT-support bliver lagt ned af brugeropkald. Vi må genstarte IT-systemet. Data er desværre tabt og må genoprettes manuelt. Kunderne må informeres. Vi søger efter årsagen til nedbruddet. Vi håber vi har lavet de nødvendige rettelser og håber på at det ikke sker igen.
4.2. Håndteretbart: En alarm informerer os om et problem. Vi genstarter systemet, backup sikrer at data ikke gik tabt. Logfilerne viser, hvad årsagen var. Vi retter fejlen. Bygger test til at undgå samme fejl igen i fremtiden. Systemet er dermed bedre end før.
For at lede sig selv eller andre skal man hver dag kunne bedømme egne og andres kompetenceniveauer.
Men hvordan gør man det hurtigt og let?
Jeg har personligt brugt SOLO-taksonomien (Structure of Observed Learning Outcomes), som er en model, der beskriver niveauer af forståelse og ansvar i fem trin.
Hvordan kan man lege med SOLO?
Vi vender den lidt på hovedet og spørger: “Hvad er din undskyldning for at fejle?” (især indenfor en kompetence)
For vores undskyldning afslører ofte vores kompetenceniveau!
For at gøre det lettere, så sætter vi niveau 1 til 3 sammen:
🥉 Niveau 1-3 – fralæggelse af ansvar
og give noget/nogen skylden: Jeg kunne ikke løse opgaven, fordi opgaven var en dum.
med en god grund: Der var ikke nok tid.
med flere gode grunde: Systemet drillede, opgaven var uklar og jeg havde ikke nok tid.
🥈 Niveau 4 – begynder at tage ansvar: Jeg må prioritere skarpere og forventnings-afstemme bedre.
🥇 Niveau 5 – tager ansvar også for egen udvikling: Jeg har løst den så godt jeg kunne i dag. Hvis jeg kan gøre det bedre i morgen, så gør jeg det!
Denne metode har jeg ofte brugt med stor succes. Især fordi mange mennesker kommer med deres undskyldninger helt frivilligt! 😄
Hvad med dig?
Hvilke undskyldninger bruger du selv?
Hvilke undskyldninger hører du andre bruge?
Hvad tænker du om alt dette?
Skriv gerne en kommentar!
Og næste gang du hører en undskyldning, så spørg dig selv: hvilket niveau taler I på?
Original source: https://labs.sogeti.com/automation-is-coming/
How AI will disrupt the developer and IT-architect; and what can they do about it?
You might be in your 20s, 30s, or 40s and surfing on the wave of brand new technology with no fear of “what’s to come”. We know that AI (Artificial Intelligence) with its Machine Learning and Cognitive Automation is surfacing below the deep unknown waters and that they will disrupt the industries within the transport, fast food, and farming sectors. We even know that the disruption will not only influence the blue-collar workers, but almost every job profile is also affected by accountants, lawyers, medical practitioner up to data scientists already in touch with AI. The questions we will treat here are, how will this AI revolution influence software development, and therefore the developer and IT-architect? What should you expect from the upcoming world of the 2020s and how should you prepare for it?
To understand what will happen in the 2020s we need to review what has happened in the last 61 years in the field of AI.
THE HISTORY OF ARTIFICIAL INTELLIGENCE
The first machine learning program and neural networks
The concept of “learning machines” is not new. The first electronic device that was able to learn and recognize patterns [Cor57], was built as early as 1957 by Frank Rosenblatt. The first machine learning prototype was built in 1961 by Leonard Uhr and Charles Vossler [Pat61]. Neural networks have existed for a long time, but their learning required a lot of labeled digital data, which was rare and expensive in the 1960s. In today’s digital world, especially social media deliver huge amounts of labeled date every second. Sensors were also analog and not very precise compared to today’s sensors in phones, smart homes, and cars. This is probably why chess was so interesting to automate because the sensory data input was simple (only 8×8 tiles and 12 types of bricks) but could result in at least 10^120 probable chess games [Che], which is larger than the number of atoms in the known observable universe [Uni].
The chess game itself was simple enough to code but winning a chess game was not. It was obvious that neural networks had a potential, but no neural network at the time was able to beat a human chess champion.
The 2000s
Something happened in the 2000s, that made AI move forward and solve problems AI couldn’t solve before. DARPA arranged in 2004 a self-driving car competition: “The DARPA Challenge”. No car managed to complete the course and the longest driven distance was 12 km.
DARPA tried again in 2005 with completely different results: 23 of 24 cars managed to beat the record of 12 km, where 5 of the 24 cars managed to complete the whole course of 212 km. What happened? The incredible improvements of big data, affordable HPC and deep architectures, e.g. digital online maps became available, image analysis tools became better, etc.
Deep learning
Software engineers and scientists required fewer data to build e.g. an image recognition algorithm, than a neural network required to learn to recognize images. In the late 2000s enough labeled digital data was available for machine learning software to remake the same image recognition algorithms, that humans already had developed. Deep learning was one of the machine learning methods, that split the learning into multiple layers. The first layer learned to recognize simple forms from pixels. The next layer learned to recognize faces from simple forms. The state of the art is that machines e.g. can diagnose diseases on the basis of images and do so better than corresponding human specialists
Not only did deep learning remake the previous image recognition algorithms, it even improved them. Machines didn’t only recognize items on images but also began to create its own images called “computer dreams” [Ifl]. Machines even began to change summer to winter on existing photos and even change day to night and the other way around [Pix]. The machine learning algorithms were not new, but the new huge datasets gave new possibilities.
WHAT TO EXPECT?
Software development by humans
Software is all about mapping the inputs with the correct outputs to solve specific problems. A software engineer or a computer scientist could take a complex real-life phenomenon and refine the necessary patterns into an algorithm:
Software development by machines
Most machine learning is only about connecting inputs with outputs, but machine learning based on evolutionary algorithms are able to improve itself by putting pieces of codes together into completely new algorithms. This type of evolutionary development is a lot faster than traditional human software development.
In 1997 humans managed to develop Deep Blue, the first computer that was able to win a chess game against a human world champion. It took 20 years, before AlphaGo in 2017 was able to win the board game Go against the best player in the world.
AlphaGo Zero (a new version of AlphaGo) was developed based on reinforcement learning. AlphaGo Zero learned itself to play Go from scratch in only 4 hours, after which it was able to beat the original AlphaGo 100 times in a row [Dep].
A machine was able to create a better algorithm in only 4 hours compared to the 20 years the multiple developers and architects needed. Developers and architects will be disrupted, but there will still be a need for humans.
It might not be fair to compare the human development time to only training/learning time of the machine since it also took some time to develop the training/learning algorithm. What we have to remember, that the training/learning algorithm can be reused for other projects, while the human development time will not.
The risk in not understanding
Software in the last 70 years has been built on simple algorithms that are understandable by humans (even though they are still difficult for humans to understand). Machine learning software can create a new type of algorithms that are much more complex and impossible for humans to understand. We are much more dependent on our software today than ever before, and not understanding the algorithms behind our software will be a huge risk to take.
The consequences are not dire, when weather-chatbot mistakes the word “tonight” with a city name, as asking the weather-bot “What is the weather tonight?” would only result in a bad answer: “I don’t know ‘tonight’. Try another city or neighborhood.”. Word mistakes such as that would have far worse consequences for a critical healthcare system, especially, if no human was able to fix the problem. Some would say, that these mistakes happen because AI is still in the early stages of development and it is only a question of time before these mistakes won’t happen – but will they?
Complex algorithms are not perfect
Kurt Gödel proved with his incompleteness theorem, that all systems are incomplete, even math. I have simplified Gödel’s proof into:
For a sentence to be true in math, it must be proved.
But what about: “This sentence is unprovable”? If this sentence is true, then it can’t be proved and therefore false according to math.
The bad news: Complex algorithms created by machines are also systems and therefore incomplete, imperfect, flawed, and containing unexpected bugs.
The good news: A chess algorithm does not have to win all possible games. It just needs to win more times, than the current world champion. If humans could design a healthcare system as a board game, then machines would find better and better ways to win this game. If humans could design a healthcare system as a board game, then machines would find better and better ways to win this game, just like AlphaGo Zero managed to win the board game Go better than any human could.
Test Driven Reinforcement Learning
In traditional development of machine learning, a dataset is split into training data (80 %) and testing data (20 %). The training data is used to train the machine, while the testing data is used to evaluate how precise a machine is to predict/categorize. Data that reduce the precision is removed from the dataset, while data that increase the precision is added. Building, navigating, and improving the datasets require a data scientist or someone with a lot of mathematical, statistical and technical know-how. This restricts a lot of people from working with machine learning.
Reinforcement Learning is about rewarding and punishing behavior to either reinforce wanted behavior or diminish unwanted behavior. I have built a prototype: A bot that has to follow a target. The bot has 4 cameras (one in each direction) and a leg (so it can move in a direction). The bot would start moving the leg randomly. To reinforce a leg movement a developer could set up a technical test, that measures the distance between the bot and its target. If the distance decreases, the probability of the leg movement would be reinforced, but if the distance increased, then the probability of the leg movement would diminish:
Caption: “Visual example of how my prototype learns and unlearns.”
My prototype is even able to handle changes in the environment, because of constant learning and unlearning. If two cameras switch place, then the bot would unlearn the old camera-movement relations and relearn the new ones.I named this approach TDRL (Test Driven Reinforcement Learning) and is completely different than traditional development of machine learning. Instead of preparing the dataset for a machine, the machine gets access to an unfiltered dataset or environment. The tests will govern the development of the machine and whenever a machine behavior needs to change or be fixed, then a new test case can be written. For example, Microsoft deployed an AI chatbot “Tay”, that became racist within 24 hours. If this was built on TDRL, then this could have been easily fixed by adding a test case that measures the racism level within a sentence. The chatbot would then fix the problem itself, by governing its own sentences and lower the probability of writing something racist.The book “Testing in the digital age” [Tes2018] describes, that we will not only need technical tests (like in the example above: “measuring the distance”), but also ethical and conceptual tests (like measuring mood, empathy, humor, and charm) to improve robots in the roles of a partner, coworker, or assistant. Technical tests will be less complex to design, while the ethical and conceptual test will be more difficult. Ethical and conceptual tests would require domain-specific knowledge. For example, the concept of “health” or “happiness” can be perceived differently: Something that is healthy for me is not necessarily healthy for my children, or the planet’s environment.SummaryHow will this AI revolution influence software development, and therefore the developer and IT-architect?There is no doubt about that the AI revolution will disrupt the IT-industry in the 2020s. Machines will be able to create better and more complex solutions, in less time, than a human developer and architect ever could. Machines will even disrupt the data scientist.What should you expect from the upcoming world of the 2020’s?We already see the need to govern machine learning bots and this need will only be growing. To govern the machines doing software development; developers and architects will have to design tests and guide the machines in creating software and solutions.How should you prepare for it?There is already a need to design ethical tests, like for Microsoft’s AI chatbot “Tay” that became a racist. But before ethical tests can be implemented, a new set of development tools need to be developed from current TDLR prototypes. As a developer or architect, you will have the opportunity in the next few years to become a part of the development, and get the experience needed to not only design the technical tests, but also the ethical and conceptual tests. The book “Testing in the digital age” [Tes2018] is a good start to find out how to deal with these new challenges. Ethical and conceptual tests will require us to answer difficult domain-specific questions such as “what is a good partner”, “what makes a good product”, “how to make the customer happy”, etc.. These questions are important, and as a developer/architect in the 2020’s we will be answering them!
Bartek Rohard Warszawski defines “knowledge” as the ability to predict a future – if you can predict something, then you can prepare for it.He has almost 30 years of experience within software development and testing, which he uses, when he speaks at conferences, writes articles, and holds workshops in TDD and test automation.Email: Bartek.Warszawski@Capgemini.comLinked: https://www.linkedin.com/in/bartek-rohard-warszawski/
In this article about “AI-learning (E-learning 3.0)” series, we delve into translation of code, to make it easier to understand. To show that AI is also about learning and not only automation.
What is Gherkin
Gherkin is a domain-specific language that makes it possible to describe software behaviors in a human readable syntax. It’s primarily used to write structured tests that can be understood by non-technical stakeholders, making it a crucial tool in Behavior-Driven Development (BDD).
We usually write Gherkin language with: Given, When, and Then.
Let’s make ChatGPT 3.5 translate the code to Gherkin and back:
I have the following python code, and I would like you to add Given, When, Then comments into it, so they explain the code:
--
number1 = 1
number2 = 2
result = number1 + number2
print(result)
--
And the result is:
Translating from Gherkin
Let feed ChatGPT 3.5 with:
Can you please translate the following text into Python?--# Given there are two variables named numbers with values: 1 and 2# When they are added together into a result variable# Then the result variable must be printed.--
It will give the following output:
Isn’t Given, When, Then for testing only?
It is for testing, but not only.
Given, when, then is a fantastic way to describe processes, and this is how LEGO manuals work and even IKEA.
Given You have the following LEGO bricks (don’t start without them).
When a some of the bricks are assembled in a specific way.
Then a specific result must be achieved.
When the next bricks are added.
Then the next result must be achieved.
…
Then the final result must be achieved.
It has been working well for LEGO and IKEA for many years.
Code is also an automated process.
By adding given, when, then comments into my code, it can make me structure my code much better.
Under the given: I can structure my variables or deal with null-pointers and other errors.
Under the when: I can do what is needed by the code.
Under the then: I can handle the clean the output and return it.
This makes our code clean and easier to understand.
And when it is not possible to structure code like this, then maybe it is a sign, that the code needs to be split up into smaller parts and simplified!
In this article about “AI-learning (E-learning 3.0)” series, we delve into translation of code, to make it easier to understand. To show that AI is also about learning and not only automation.
Transcending Language Barriers in Coding
One of the most formidable challenges in the world of programming is the diversity of languages. Python, JavaScript, Groovy, and C# — each serves its purpose, but fluency across them can be daunting. Enter ChatGPT 3.5, an AI model that acts as a linguistic bridge, effortlessly translating code from one language to another.
So, if I take the following code:
Python
# Givennumber1 =1number2 =2# When result = number1 + number2# Thenprint(result)
and put it into ChatGPT as:
Can you please translate the following Python script into JavaScript:--# Givennumber1 = 1number2 = 2# When result = number1 + number2# Thenprint(result)--
Then the result will be in ChatGPT:
We can translate it into Groovy, C# or any other language!
It’s especially good, when you need to do something in one language, but don’t understand what this method does. Python code example:
Python
pn =str(n).zfill(5)
and put it into ChatGPT 3.5:
Can you please translate the following Python script into JavaScript:--pn = str(n).zfill(5)--
and it gives the following result:
and same goes for the other languages:
Groovy:
C#:
How cool is that?
You are welcome to try the code out directly in the browser, by using web editors: 💻Python / 💻JavaScript / 💻Groovy / 💻C#
You can also try yourself with PHP, Ruby, C, C++, whatever!
Part 2 of 2 – Translate between Code and Gherkin with AI
Have you ever imagined that learning technology could be filled with as much fun and imagination as creating your own art? Welcome to bartek.dk, where we turn that imagination into reality!
I’m Bartek, a Quality Coach, Test Engineer, and an AI explorer.
I’ve witnessed first-hand the transformative power of AI across different sectors. However, it was the integration of AI into my own field that illuminated a path less travelled.
My mission is to bring the playful spirit of kawaii (Japanese for lovely, adorable, cute, etc.) into the world of coding, testing, and automation.
Why should testing and coding be all boring and only serious?
Let’s find the fun in it!!!
Crafting Automation Scripts: Your Digital Magic Spells
Remember the wonder of seeing a machine do something amazing for the first time? That’s the thrill of learning to code!
We’ll guide you through creating automation scripts that are incredibly fun to build but also fulfilling to watch in action. It’s like when my grandmother got her new washing machine and watched it do its magic.
And why not learn it with the AI-tools of today?
This is not another: “Learn to program” course. It’s a new way to do it with AI!
But how do you make sure your digital creations do exactly what you want them to do, every single time?
That’s where testing and Test-Driven Development (TDD) come in. We’re here to demystify these concepts, showing you step by step how you can be the master of your code. To learn how you ideas actually work and what system-behavior actually needs to be implemented!
Precision in Communication: Beyond AI Guesswork
I had a dialog with Alan Turing (simulated with AI), about the future of programming. He pointed out, that programming is not dead, but more needed than ever before.
In a world increasingly run by AI, the need for precision in our commands and codes has never been more critical.
Yes, AI can guess what we need from our prompts written popular language, except it often guesses based on the majority’s needs.
TDD provides us with a tool for communicating our deepest thoughts and wishes to the computer and AI, ensuring our creative vision comes to life exactly as we imagine.
The future of programming is not dead, but programming languages will go from hardware-specific to concept-specific.
Are You In?
Ready to embark on a journey where learning coding and testing becomes a canvas for your creativity?
Aided by the charm of kawaii and the cutting-edge capabilities of AI?
Let’s not just code; let’s inspire and be inspired, blending the artistry of programming with the precision of TDD, to express our self and grow in areas we never could imagine before.
Join the adventure at bartek.dk – where coding meets creativity and imagination!
Let’s talk about learning to code – it’s like unlocking a whole new world of possibilities, right? But wait, here’s the thing: sometimes, getting started can feel like hitting a roadblock, especially when it comes to installing all those fancy tools.
But guess what? I’ve got your back! I’ve whipped up some super cool editors for JavaScript and Python, and I’ve even thrown in some existing ones for Groovy and C#! 🎉
Now, here’s the kicker – we might not be able to code anything just yet, but we’re gonna learn the basics together. It’s like laying down the foundation for a super cool coding adventure! 💻✨
Stay tuned, because I’m about to show you the ropes in these editors. And get this – we’re gonna dive into the world of Test Driven Development and AI too! It’s gonna be an epic journey of learning and discovery. 🌈📚
So, wish me luck on this exciting adventure, and get ready to join me on this coding quest! Let’s do this! 💪🤖🍀
Guess what? I’ve just launched a super cool music page that’s all about helping you chill out and dive deep into your thoughts like a fearless explorer! 🎵✨
Picture this: you’re in your own little world, coding away like a pro. But wait, something’s missing… Ah, that’s it! With our totally free meditation/musication music playing in the background, you’ll feel like you’re on a magical journey to uncover hidden treasures within your mind! 💡🎶
So, what are you waiting for? Grab those headphones and let the adventure begin! Check out our awesome selection of tunes and get ready to embark on a journey of peaceful coding bliss! 🚀💻
