I love visiting tech companies, talking with the engineers about their inventions, achievements and daily struggles. Discussing the problems, maybe come up with quick ideas together - basically, playing the part of the rubber duck that quacks in-between.

Most interesting are of course start-ups. Especially in start-ups Devs, CTOs and CEOs are super proud of what they do. Rightly so, most of the time. This state of mind is of course necessary to survive the early days, the pressure and struggles. A high level of motivation and personal investment is required. Time is of the essence, the product needs to hit the road as soon as possible, often the competition is closing in.

Then there is your standard tinkerer-developer. Diligent, intelligent, dutiful tech-lover, the sort of nerd you want to get the job done. But with that often comes the mindset that everything that can be done by oneself shall be done by oneself. And that is a bad mistake.

Often when I ask, “How’s your build pipeline doing?” or something of the sorts I get the proud story of how they just bought a huge server for 10-40k €, they got a git repo running there, they plan or already have some build automation like Jenkins set up - manually, by themselves, in many working hours. They tell me of the struggles, of how much pain the backups have been.

In a firm where you’ve got maybe 2-5 developers and there’s tons of tasks that are crucial for your product waiting in line, that is not really efficient. Why would you invest so much time and effort in something that is readily available and cheap? Gitlab and co, backups via Restic to Backblaze, everything is there and ready to use. If I challenge their statements, I usually don’t get straight answers. “Have it inhouse, secure” - yeah you don’t believe that yourself. “But we just bought this super expensive server - it would be a waste…” - yeah, that was a wrong decision in the first place; but now you also add the classic sunk cost fallacy. “The subscription’s too pricey” - no it is not. You don’t really save money here if you do it yourself, I promise. It’s not only the effort of setting it up, also maintaining it is costly. If the company is large enough to have devops and integration engineers - yeah sure, go wild! But not when your team is smaller than the A-Team and every member is crucial.

That brings me to the next point. I thought in the (almost post-) age of Agile and Scrum, the truck factor topic would be yesterday’s news at least in new, young and dynamic companies. Again, think of a small office, just started out with let’s say three developers and ambitious plans. You’d think these three would develop the tasks together, hold little get-togethers where they talk about what they do and how, and get feedback from their peers. They’d face challenges, solve problems together. Everyone knows every aspect of the code base.

Well, far from it. Maybe from stress, maybe from how they used to work during their studies, maybe out of pride, everyone’s a lone wolf warrior. Everyone’s got his or her claimed piece of the code base, their code. Nobody else touches it. Nobody knows it or dares to change something. That’s of course because you never know the “inventor’s intentions”, and there are no unit tests so how could you be sure that everything is working as expected if you changed something. Again, a bad mistake. Really toxic for the firm, but also for the developers themselves. Yes, you made yourself indispensable to a certain degree. But that means that vacation planning will always be a pain. That means that your career is frozen, because nobody can replace you. That means if something is broken - you are the only one that will be able to fix it (in a reasonable amount of time), and if you don’t you are the only one to blame.

Believe me, it is nice to be able to talk about something in your code with a peer, and that peer knows exactly what you are talking about. You bond over it. Sharing is caring. Problems are solved faster, better, if more minds are involved. Do mandatory reviews. Do pair-programming, do it often. Do stuff together. Most importantly, talk about it, a lot. Take a coffee break and tell people what you accomplished and what irks you at the moment. You’ll get praise for the former and come quicker to a solution in the latter. It’s better for everyone involved. Use unit tests - one writes the actual code, another the test. You are going to discuss corner cases and behavior. The software reaches higher quality and the code is indefinitely more shareable because it takes the fear from your colleagues to also change your code. Use tools for reviews, daily (or check-in) builds with automatic tests, apply some form of agile. I don’t say “live by the agile manifesto”, just cherry pick at least the most important ideas (dailys, small tasks that are distributed over all devs, stuff is only done when it’s tested,…) and live them.