Published on May 14, 2016
Author Lars Kruse

Praqticum - the internship approach at Praqma

Thinking about an internship at Praqma?

Thinking about an internship at Praqma? Learning new stuff and improving existing techniques and tools is the most important ability that we can provide to our customers.

Many of the tools, techniques and approaches we juggle are brand new - To claim ourselves expert status within these, we need to be good a learning

You can’t alway recruit experts

In our line of business - being a service bureau within a niche - our company is essentially defined by the people we employ. As we’re constantly employing more people, our company is constantly evolving.

Obviously we want to employ people who are already experts and proficient in our line of work. But the paradigm we work in is relatively new and there aren’t that many experts, so it can not be our only strategy of recruitment.

Sometimes we need to be experts in technologies and tools stacks that are so brand new, that whoever want’s to call them self an expert will have to become one - through learning.

We started using Gradle when there didn’t even exist a language description. We’re partners, certified trainers and consultants in Docker - a technology that - at the time of writing - just celebrated 3-years birthday. We developed our first three Open Source Jenkins plugins, back when Jenkins didn’t even exist and it was still called Hudson.

A lot of the time, you will have to grow your own experts

That is why Praqma has a very distinct and conscious strategy for learning stuff. We’re quite ambitious about it and that’s one of the reasons why we like to host internships. We like to work with people for a while to see if they dig it because if they do - dig it - then it’s our experience, that young newly educated professionals can be as much experts as your neighbor.

It’s all about the applied approach to learning and the attitude of the person.

Cognitive Science - the science of knowledge

Cognitive science is the interdisciplinary scientific study of the mind and its processes. It’s a field that lends from artificial intelligence (AI), philosophy, psychology, linguistics, neuroscience and anthropology. The field originates from the 1930’s and 40’s where it emerged as an attempt to support development of AI. To develop intelligence, you need to understand it. Cognitive Science focuses on how information is represented, processed, and transformed.

When I wrote my master thesis - almost 20 years ago - the topic was to explore the learning processes as a software designer; Can you pour learning on bottles and drink it? Is it possible to be operational end decisive, despite the potential lack of experience in the field?

Sources of inspiration

I’ll give you an insight in some of the inspirational sources and theories that helped me back then, to build the vocabulary and some of the ideas on how to put the pedal to the metal in a learning process. Of course the books that inspired back then are ancient today - and who reads old books? Well, the matter of the truth is, that they are still very much valid. And if for nothing else they remain useful, because we’re still using some of their vocabulary and approaches today - inside Praqma.

In “The reflective practitioner1 social scientist Donald A. Schön from M.I.T. presents a study of how professionals go about solving problems. The assumption is that professionals know much more, than they can possibly put to words. So how can we learn from them if they can not articulate it or put it to formula?

This idea, that there exist tacit knowledge, which isn’t easy to put into a language and transfer, was originally presented by physicist and polymath Michael Polanyi in “Personal Knowledge2 and has later inspired - and set direction - for a lot of the scientists in the cognitive science field. The two brothers Hubert and Stuart Dreyfus presented a model in their book “Mind over machine3 with 5 stages of skill acquisition from - novice to expert. On the expert level the Dreyfus brothers go:

An expert generally knows what to do based on mature and practiced understanding. When deeply involved in coping with his environment, he does not see problems in some detached way and work at solving them, nor does he worry about the future or devise plans. We usually don’t make conscious deliberative decisions when we walk, talk drive or carry on most social activities. An expert’s skills has become so much a part of him, that he need be no more aware of it than he is of his own body.

If we accept the premise that there, inside experts, exist knowledge which is more like recognition; they know it so deeply, that it’s like an integrated part of their body. Then wouldn’t it be cool, if we could have a method, that could either transfer this knowledge to novices or at least support novices to get to that level of recognition in a faster pace?

In context of software development a fellow named Erik Stolterman finished his PhD at Umeå university back in 1991. His publication was titled “Designarbetets dolda rationalitet”4 which roughly translate to “The hidden rationale of design”. He’s on the same track as Schön, Polanyi and the Dreyfus brothers. In his study he’s trying to frame; how do designers succeed in what they are doing, when clearly just following a process isn’t gonna cut it. His conclusion is that professionals have an inner compass for what is right. It’s a measure of quality, that not only relies on reason, but even on aesthetics and ethics.

The interpretation is that as experts we need to develop a lingo for what’s good and what’s beautiful.

Hold that thought!

Back then - 20 years ago when I wrote my master thesis - the paradigm we defined ourselves to belong to was referred to as Participatory Design, a discipline within computer science advocating that there exist both theoretical, pragmatic and even political arguments why users should participate in the design process.

In the context of all this isn’t it just magical to revisit the agile manifesto - and remember it’s from 2001:

Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan The agile manifesto trust that developers knows what’s good and beautiful, it advocates end-user participation, exploration and experiments. Essentially the agile manifest it telling us to behave like expert professionals: Cognitive Science meets Participatory Design!

Schöns world

Donald A. Schön introduces the terms knowing-in-action and reflection-in-action to describe the phenomena that experts are capable of listening to the back-talk of a given field situation and do the right thing.

An important step towards professionalism and expertise is that one learns to hear this back-talk and to trust your instincts; When you get a feel that something is odd or not right, it’s probably because it’s odd or not right - and you should react on that with experiments.

According to Schön experiments comes in three different flavors:

  • Exploratory experiments - done simply to explore; Do something different, with no other purpose than to get a different result - then analyze it.
  • Move-testing experiments - done to test a certain move; Do something based on the assumption that it will give a specific outcome - and evaluate if you get the expected result
  • Hypotesis testing - done to verify or reject a hypothesis; Do something that challenges something you think you know, goal is to turn that knowledge into recognition.

Analyzing the outcome of the experiments is referred to as reflection-on-action. So to master reflection-in-action you will practice reflection-on-action (on vs in …you get it?).

In order to get to a place where you can conduct experiments, you need to have the situation talking back to you. To achieve that, Donald says, it is imperative that you work with real world problem - not theoretical constructed ones. Donald advocates that students need to get outside the safe and guarded environment of the university to learn this.

What you need to do, is to create what Schön calls a practicum. A situation that resembles the problems that the students will later face as professionals, but with a frame around it that narrows it in. The narrow practicum has the purpose of guaranteeing, that the student will bounce into the boundaries of the practicum, this way it’s guaranteed that there will be back-talk from the situation. The student use the practicum to learn how perceive and listen to the back-talk of the situation and to conduct experiments which is then reflected upon in retrospective, to be able to achieve the goal to do it in-situ.

The Praqticum at Praqma

When inters work at Praqma we set up a practicum like Schön describes it - we call it a Praqticum.

  • The goal of the internship is to deliver the Minimum Viable Product (MVP) in the hands of the end-users - within the given time frame.
  • The product shall have a continuous delivery pipeline that automatically checks the product’s definition of done.
  • The pipeline shall as minimum include a production-like environment and an automated deploy process.
  • The code shall contain unit tests.
  • The code shall be version controlled in Git using a release train branching strategy.
  • The integration branch shall be kept pristine (unbreakable).
  • The project shall be managed using a Kanban approach, all tasks shall be groomed before they are worked on.

A praqticum like this will - for sure - generate some serious loud back-talk from the situation.

Usually we also ask for interns to apply in groups, partly because working in teams is what professionals do, and that too will contribute to the back-talk. But the teamwork is also required simply in order to be able to reach the MVP in time. The task is always relatively big, because the complexity that comes from size is also a common ingredient in real life projects.

Most often, that interns will produce a delivery into an Open Source project in an existing community, maybe it’s an extension to one of the many Open Source projects we already have, or it’s something completely new. But regardless of the character of the Open Source project, the fact that it’s Open Source adds even more real world flavor to the praqticum; Open Source shall be released to the community, it shall be documented and it might even encourage additional content like published blog posts.

This is the world of professionals. This is what interns meet when they start at Praqma.

In the process interns work in the same workspace as our consultants, they sit right next to each other and there will be plenty opportunities for the interns to ask for advice, or have the tool-stack demonstrated. The interns will have an appointed mentor throughout the process and the product will have an assigned Product Owner.

What we hope to achieve by this process is two things, one of them is obvious; We want to see if the interns dig it. If they do, then they are clearly Praqma prospects and we usually offer them jobs.

The other thing we hope for is that, we ourselves, manage to optimize the learning process in general, so that we will not just be good at Continuous Delivery and DevOps, but that we, as a company, will be able to refine and optimize the process of learning - in general. We too seek to contribute to the ideal within cognitive science - that learning to learn is something that can be taught.

If you’re interested in an internship praqticum at Praqma, then send your application to it should contain a cover letter, telling about yourself and what you hope to achieve.


  1. Schön, Donald A.: “The Reflective Practitioner:”, 1989, ISBN: 1857423194 

  2. Polanyi Michael: “Personal Knowledge”, 1958, ISBN: 0226672883 

  3. Dreyfus, Hubert L. & Dreyfus Stuart E.: “Mind over Machine”, 1986, ISBN: 0029080614 

  4. Stolterman, Erik: “Designarbetets dolda rationalitet”, 1991, ISSN 02820579 

Related Stories


Developing Embedded Software with DevOps

A guide on how to improve development processes

Learning at Praqma

Praqma - The Knowledge Company

Working at Praqma

Breaking the rules of consulting