6 minute read

…or join us as a Junior Developer

Our community is for joint development of products and features. But it is also a carefully designed training field - a dojo where you can come and do your katas. Read on if you are studying a relevant topic at B.Sc. or M.Sc. level and you are looking for either a full time internship or a student job in real tech.

Tech Collective

In The Tech Collective we’re fascinated by the concept of building quality in - as opposed to try to glue it on to the product after it’s released. This concept is not new at all. It’s an ideal mentioned in the Agile Manifesto. It’s the core of Continuous Delivery and the DevOps Culture. And it’s why we strive for Automated testing - well, why we strive for Automation in general.

Anything as Code

We believe in anything as code.

If “whatever you’re trying to achieve” can be solved by a snippet of software, then your solution is software. It’s code! And we know how to deal with code:

When code is done right:

  • It’s programmable
  • It’s immutable
  • It’s semantically version controlled
  • It’s automatically tested
  • It’s documented
  • It’s componentized and dependencies are managed
  • It’s released as packages
  • It’s maintained

Alright, this may not sound like a big deal. But it is!. We will turn up the ambition a notch and claim that the properties mentioned above are not optional - they are required. Hereby we enter into a quite complex field of software. We’re not merely programming or hacking anymore. Now we have to deal with the entire eco-system that surrounds code.

…as code!

“We’re making software, that software developers use, when they make software.”

We enter into a world that may seem hidden or secret to a majority of most software engineering students. Or if they do know it, they’ve probably only just barely scratched the surface. But it is a big world, one of infrastructure as code, cloud computing, declarative pipelines, automation, artefact management systems, static code analysis, testing frameworks, production-like environments, CLIs, APIs, a lot of scripting, containers, IDEs, deployment tools, domain specific programming languages, extensions, plugins, distributed version control, dash boards, chat bots, social coding platforms, a lot of YAML, package managers, platform engineering, Internal Development Platforms, Developer Experience, Citizen Development, FlowTech.

If this world is of interest to you, then you would love working with us at The Tech Collective - this is what we do. And we have a programme where we offer both full-time internships and part time student job positions (≈20 hrs/week) to B.Sc and M.Sc. students prom relevant studies and who share our values.

One-piece-flow

When Toyota faced the problem of building quality cars with small means, with scarcity of basically all resources, including funding, and entering into a playing field where the competition at that time was 1000s times better prepared than themselves, they took an entirely new approach that has inspired the world - and especially the software industry - ever since; The Toyota Production System (TPS) or lean as it was named when used outside Toyota’s own sphere.

They were the ones who came up with the ideal to build quality in - as opposed to glue quality on. The Japanese word is “jidoka”. And some of the core principles they applied to achieved this was “kaizen” - Continuous Improvement and “kanban” - Signaling.

In Continuous Delivery, DevOps and Automated testing we’re especially inspired by Toyota’s one-piece-flow. Toyota built an assembly-line that was deliberately designed to make problems surface immediately. They would not build individual components for stock - and then later assemble them. Instead the would organize the assembly line so that in the start there was nothing - and in the end there was a finished Toyota, ready to be shipped of to the customer. At the time, this approach was definitely not considered the most efficient way to build cars - but is should proof that it was definitely the most effective (the subtle distinction between efficient and effective is deliberate).

It had a huge effect! A lot of problems surfaced. All the time. In fact so many, that in the beginning they had a hard time delivering cars at all. Most of the time the factory was at a stand-still; fixing problems in the one-piece-flow through means of kaizen - continuous improvement and reorganizing the tasks to adhere to the concept of kanban - signalling.

The story of The Toyota Way has many more nuances than described in the three paragraphs above - But for now it’s sufficient to make our point; that a holistic view based on system thinking and problem solving is also at the core of how we work. And The Toyota Way is definitely worth diving deep into.

Enter our dojo - do some katas

The field we’re entering can be referred to as Software Development Life Cycle (SDLC) management or by terms such as Continuous Delivery and DevOps but no matter by what term we name it, it’s build on the same one-piece-flow mindset as Toyota introduced. In realty though; this is very complex - by nature probably even more complex than building a car, due to the inherently intangible nature of software.

In The Tech Collective we build and continuous improve this eco-system. And we’re inviting you to join us. Every time we release a small snippet of code, we will optimize and establish this eco-system around it. This eco-system around code is essentially what we help and assist our customers in establishing. We make sure that the characteristics we define for code-done-right apply. We construct one-piece-flows and hereby guarantee that problems surface early, then we solve them - continuously, and eventually we build quality in - Jidoka.

Wax on - wax off Toyota also adopted the concept af katas - In karate a kata is an exercise, a series of movement you train over and over again, until you know them by heart.- Recall Danny Larusso - The Karate Kid, when Mr. Miyagi forced him to wash and polish cars “wax on - wax off” That was a kata.

As an intern or a junior developer (part-time employee) you will contribute to the products in this community, by delivering code that is done right - in a one-piece-flow. The long-term perspective in an internship or a position as junior developer with The Tech Collective is of course, that you fall in love with us - and we fall in love with you. And when you are done and graduated - you are accepted as a full-time consultant in The Tech Collective tribe.

The demand for the products and features we build comes from clients, colleagues, ourselves or trends in the market.

We will build, release and maintain products based on principles typically used for developing Open Source code - a.k.a Benevolent Dictator Governance Model. We maintain road maps and backlogs, we tie all commits to concrete tasks that are prioritized based on principles for kanban task management. We work work in build-measure-learn cycles around Minimum Viable Products. We steer and either pivot or persevere based on the feedback we get from our users. We work in a Social Coding environment to expose a showcase of an Internal Development Platform.

Reach out - touch faith

Personal Jesus A common prediction these days is that more and more software in the future will be done by chats and generative AI, but the eco-system that surrounds software - generative ai included, is so carefully adapted the individual team, organizations, tool stack and domain knowledge, that this is not merely distilled wisdom of the crowd which is the force og Generative AI. It calls for sophisticated thinking and rehearsed problem solving skills. “Reach out, touch faith” is the chorus line in Depeche Mode’s legendary hit “Personal Jesus” - We offer you a chance to reach out and touch faith; start building your own personal career in software and tech.

If software is truly eating the world - you job should be to tame the software.

Lars Kruse
lakr@thetechcollective.eu

Comments