Our job in the lab was to create new hardware and make it work. Then both dedicated team and cloud team would send an order depending on what they expected to sell, and we would support both throughout the lifetime of the hardware. This was our mission. Keeping this in mind was important. It was important because we could often get distracted from it.

Some of our tools were written in old languages. We used old software tracking systems, and we used old version tracking software. There was this itch to update them. To redo them in a new shiny language or use a shiny new tool. Sure maybe it would be fun; however, that was not our mission. Our mission was not to redo the tools that we used. If the tool became a constraint, we would change it but it was only a tool. The shiny was the chips or the shiny was how they were interconnected. It was not using a newer language or a language with a lot of hype to redo the flashing tool.

We did not have shiny macs or powerful Linux stations. Most of our tools worked only on Windows. Sure we could change tools, sure we could maybe use open source or contribute to these tools, but, in the end, what was the added value for the team and the company to do that? The work was very time and cost intensive with multiple colliding timeframes. Yes, we used Windows, yes we coded in a putty terminal, yes the laptop was bulky and ugly but that did not change the work we did.

Scaleway tried to get traction on hacker news as well, but it didn't work that much. I don't know if it was the way the communication was done or if hackers were not interested. It's also hard to tell the interest in technology. I could try to spend time arguing online and hyping up interest. What would it bring in the end? It would not make the hardware work by itself.

At first, it was hard to resist those urges. But as time went by, it became easier. The sheer volume of work to make the hardware work crushed any time we had to do these kinds of things.

This did not make the hardware we produced less useful. We knew what we were doing, and we had internal validation because we directly talked to our customers. The whole idea was to reduce the cost and simplify the workflow of other teams. The cost we could calculate. On the other hand, the workflow we could not know. We had to talk to people, ask questions and fit in their model.

The most user friendly features did not come from me or the hardware team. They came by observing how the hardware was used, how they handled other hardware and trying to fit our model to make life easier for them. The netlink feature and the ipmitool feature saved many hours for them because it fitted directly in their information system. It was plug and play.

To do support, we had to write a lot of documentation. How everything was wired from an outsider perspective, workflows to put into production, binary artifacts for multiple distributions and procedures to diagnose issues. We also collected different bug reports and fixed issues with new releases.

It was a very important part of the job. We might have ideas on how hardware should be but didn't handle hundreds of servers or routers on a day to day basis. We could improve density, but it would only be useful if the people installing these could manage the increased density and make a profit out of it. If the system was too complicated to use, it did not make sense to add so much effort into producing it.

To pair with :

• Don't Know - Sd Laika
• Hackers: Heroes of the Computer Revolution by Steven Levy

If you have missed it, you can read the previous episode here​