DEV Community: Phil Wilson

Learning: First principles and patterns

Phil Wilson — Wed, 16 Feb 2022 11:46:23 +0000

Oscar, 5, finished his breakfast this morning, jumped down from his seat with a bottle of water in his hand, and washed down the last mouthful. All in one fluid motion. Then he stood there for several seconds, motionless, his face frozen in deep thought. I watched him from the other side of the room as I sipped the first coffee of the day, trying to guess what was happening in his young mind. Eventually his eyes began to move again, and he turned his head to me, his expression changing to one of confusion. "Dad" he began "I've always wondered why when we drink, we can just swallow, but with food we need to chew.".

Perception vs Conception

I've observed in some friends and family that when a child asks them a question, they rush to answer it. And when they do they often tend to tell the child the answer, as if plucking a memory from their brain. The memory is how they perceive the answer. A story. An interpretation of how their senses tell them the reason "why". Here this type of answer would have been something like: "We need to chew our food so that we can swallow it." or maybe "If we don't chew our food it gets stuck in our throat".
This does convey an answer, and it's in no way wrong. The child will come away with an adequate model of why it's best to chew their food, and not try to swallow it whole like a snake consumes an egg. But that answer is like taking a model of understanding from one person's brain, and merely trying to copy it into another's. Forcing a memory to exist, whole, fully-formed.

Recently I got a 3D printer and began the learning curve of moving from bits of stringy plastic emerging to decent quality prints. I felt the urge to find other people's perceptions on how to do this. To copy their mental model into my brain. But I knew I had to understand the principles, and build up my understanding of HOW to print good quality items. And, as it happens, everyone I spoke to about printing has also told me to take my time and understand the why. As a result, my learning has been quite swift. I can reason questions for myself by logically inferring the answer from the things I already know. When I do get chance to speak to someone already knowledgeable about the subject, I can ask focused questions, validate the principles I've learned and get concise answers back. I am conceiving the answers.

The difference in result between giving someone a perceived answer and helping them conceive the answer, in my opinion, is a stronger, more lasting understanding. With a perceived answer you are relying on the recipient using their memory to store your mental model. With conceived learning, you are helping them to understand the principles behind the answer and facilitate them constructing them logically into a model they build themselves.

Patterns

The other thing that learning from first principles gives someone, is the opportunity to find patterns. Different experiences of learning often build on top of the same principles, and so patterns of principles form which re-enforce the new understanding. I'm no neuro-scientist, but I do know that the brain is structured as neural pathways connecting neurons together. And it seems logical that learning principles and connecting them with patterns would cause a brain to re-enforce that same structure within the brain, making a stronger understanding, than trying to store an abstract mental model gleaned from another source.

Why do we chew?

As Oscar came over to me, to better hear the answer he expected me to give, I wafted the air with my hand so that it blew onto his face. "What's that you can feel?" I asked. "The air" he said, with eyes wide and focused. "Is it a liquid?" I went on. "No" and he paused, "it's a gas!". We reminded ourselves about the 3 states of matter, and spoke about how water can be a vapor, a liquid or ice. "Could you swallow an ice cube" I asked. "No, but I could suck it until it turns to water, and then drink it" Oscar replied. "Yes!" I said, "and could you swallow that sugar cube we did that experiment with the other day?" I asked, linking him back to an investigation we did about things dissolving. "No, but when it dissolved I could drink it!". "Can you remember what happened when we smashed a sugar cube and stirred it in the water?" I asked. "It dissolved quicker!" Oscar said, the patterns forming, his face lit up.

"So why do we chew our food, Oscar?" I asked.
"Because we need to try and turn it into a liquid so that it can go into our tummy" he said confidently.

Serendipity Engineering - part 1

Phil Wilson — Tue, 15 Feb 2022 09:13:14 +0000

Back in the summer of 2021 I spent 5 weeks making a Raspberry Pi into a box of puzzles, for no other reason than for fun. It's one of the most valuable things I have ever done at balena. Here's why:

Context

Since balena is a remote-first company we put a lot of thought into making sure we try to connect with each other and have fun. In the past one of the ways we did this was to spend a week, once or twice a year, to physically collect together and spend time with each other. We call these sessions Summit, and there will usually be some swag there, such as devices and SD cards and sensors, t-shirts and hoodies and snacks. However, for obvious reasons, in the last couple of years we have been unable to fly the team around the world and spend time together in the same building, so our summits have had to move to a virtual event. The first time this happened, in 2020, a group of people at balena decided to build a project (the inkyshot ) and send one to everyone on the team as part of the swag box. The idea was that it was connecting to all be receiving the same message, initially about summit itself, but latterly to share quotes and insights.

In 2021, about 6 weeks before summit, one of the team rang me up and asked if I had any ideas for a device we could build and send in that year's swag. Of course I did. I rarely have zero ideas. :) However 2021 had an additional constraint: a boat got stuck and suddenly buying hardware components became almost impossible. With only 6 weeks to think of an idea, design it, build a proof of concept, buy ~100 sets of hardware, build them and send to the four corners of the earth... it was never going to happen.
Then the idea struck me - what if we relied on the hardware the team already had, and just gave them some software? Some fun software....

Why?

So before we get into the details of the idea, let's address the crux of the post: why did I spend 5 weeks (it took me a whole week to think about it) on a puzzle for the team? Worse-still, I recruited a bunch of other balenistas to help me. So why did I spend 5 weeks of several people's time, making a puzzle?

When Yahoo banned it's employees from working at home, it stated:

"Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings."

Whilst I don't agree with the decision Yahoo made, I do agree that good things happen when people hang out together and hack on stuff. So how do we do that at balena, a remote-first company, when we don't have a coffee machine to linger around? We enable everyone to self-organise into projects to build something together, and have fun doing it.

This puzzle project I had conceived, quickly snowballed from an idea which raised a slight smirk when I told a select few people (the project was kept secret until summit), to one erupting with lessons learned, product feedback and possible future use-cases. It might even turn into another official balena product.

The idea in a nutshell

The idea was to provide the balenistas with nothing more than an SD card and a postcard printed with a QR code. The code would lead them to an open fleet on balenaHub which they could then join by flashing the SD card and popping it into a device they already had. The instructions on the fleet card in hub told them to open http://cattlegrid.local on a browser, which opened a web server now running on their RaspberryPi device. Here's how it looked:

Quorum is the minimum number of participants in a system to make it work, and at balena we use the term to mean the number of people who've joined a meeting before we kick off. This was a hark back to a previous teammate, Shaun, who used to say it all the time at the start of the weekly team meeting. I wanted this puzzlebox to tell some of the folklore to new balenistas and stir memories to those that have been here a while.

The "Devices in the herd" line would lead teammates to add more devices to the open fleet, until quorum was reached (60/100) upon which the site would redirect to a page with this image:

The page also had a textbox and a submit button.

The idea was that the user had to try and find more puzzles to solve, by inspecting the device, and each puzzle would provide a code. By entering that code, a centralised API (running on an edge device in my house, obvs) would register that the puzzle had been solved, and everyone's fleet would show the updated count of puzzles solved. This fleet was a team effort to find the puzzles and solve them to get the codes. :)

The picture of the pi was actually another hark back to some balena folklore. Alex (CEO) had sat with Chris (hairy labs geezer) looking at a pi together, trying to spot what every chip and port on it was, and whether they could think of a labs project for each one. Here I wanted a puzzle for each.
Additionally, I wanted all of the team to have a physical device in their hands (or on the desk) which they then needed to interact with. It occurred to Chris and I during this project that not everyone on the team has had this experience of physical computing. Actually making the device do something, like light an LED, or produce a noise. Connecting GPIO pins together with wires, making stuff happen! We thought it was super valuable to give the whole team the experience of interacting with real hardware.

Which brings me onto an example of a puzzle. There were puzzles hidden as WiFi access points, bluetooth pairing challenges, digital steganography delivered through the HDMI port, audio clues though the 3.5mm jack, and more. But the first one I made was using the GPIO pins. When the user clicked the pins on the picture of the pi, they got redirected to this page:

This puzzle needed them to earth the pins in a particular sequence, to unlock the code. And any wrong pin earthed, took them back to the beginning of the sequence. :D
I loved this one, because it made people use wires and pins and interact with the device in a way a lot of the team probably hadn't before.

A counter on this page told the team how many puzzles could be found and solved on the device, and when they solved all the puzzles....they were sent to a website (running on a NUC in my house) where there were MORE puzzles to solve:

Actually this is an old screengrab, we ended up with 33 puzzles for the team on this page. Each one uses a Deploy With Balena button, which puts the puzzle onto the users device. They then have to find and solve the puzzle, and put the resulting code into the main website to tick it off. The range of puzzles we had here was amazing:

turning the pi into an FM transmitter with a GPIO wire antenna, and using text-to-speech to broadcast the code
having to learn and navigate the balenaOS image partitions to find otherwise hidden files
using the UART GPIO pins to form a loopback
cryptography puzzles
balena trivia quiz puzzles
morse code LED puzzles .....etc

And we could also make puzzles that relied on additional hardware, since that just caused the team to work together to find someone with that hardware. I made a version of the Nokia Snake game that used a SenseHAT, which necessitated someone getting a high enough score to make it display the code. Not everyone has a SenseHAT, but I knew SOMEONE on the team would. :)

Next part

In the next post I'll explain how I managed to deliver to build an open fleet, an API and puzzle frontend, 33 deploy with balena puzzles, 7 open fleet puzzles, all tested and proven working inside 5 weeks WITH NO DEDICATED RESOURCES. No orders, no hierarchy, just pure gameB ways of working with others. :)

balena - 24 months in

Phil Wilson — Mon, 14 Feb 2022 13:24:26 +0000

When I had been at balena for 12 months, I wrote a blogpost about my experience so far. That post allowed me to explore my own thoughts, but it also seemed to help other people inside and outside of the company to read about my experiences. So here's the next "exciting" installment.

2021 - 2022

Straight away I'm having to browse my calendar from this time last year, to try and remember what I was doing. And that's a good sign that I don't reflect back enough, and probably lose sight of things I have accomplished.
But here's a short list of things I've focused on in the past 12 months:

Interviewing

I've become much more involved with the hiring process at balena, especially running a system design task which we ask all candidates to do. I've really enjoyed hanging out with the candidates, and trying to help shape the hiring process at balena. I'm passionate about it being fun for everyone, the candidate and the balenista. I don't want any power dynamic, I want us to be hacking on something together, and seeing if we both feel like it's a good, two-way, fit.

Coaching

I've also spent a great deal of time trying to help some people at balena who need some extra guidance with their career and with things they are working on. Candidly I've found this hard, and I'm still trying to find my way here. I care about these people, and I want them to succeed, but I'm yet to find the way to efficiently help them do that. My early approaches saw me lose a LOT of my own time and energy, and begin to lose my way with my own work. Subsequent approaches have been too "hands off" and the relationship dwindles. Definitely a WIP.

Blocks

Blocks are like code packages but for containerised applications. It's not a concept I own or control, but I am a passionate advocate for it and chief cheerleader. I've continued to make some blocks, but mostly my focus in the past year has been about communicating about blocks and encouraging others to get involved. The number of blocks on hub.balena.io has grown from 5 to almost 40, despite a pretty terrible (soon to be sorted) experience for adding them there. I've also noticed the wonderful signs of the concept gaining momentum. People are PRing fixes and features to the blocks repos on GitHub. People are answering questions about blocks in the forums. Developers inside and outside of balena are using blocks and making blocks that could help others.

Labs residencies

Once it became clear, to a few of us, that the way people tried to onboard to balena was not fit for purpose, we decide to try another way: asking new joiners to spend a month in the labs making a project of their choosing. This became the labs residency programme. I wrote more about it here. Part of that programme is having experienced balenistas guide them, which I wrote about here. Candidly, this has been HARD. There have been times I have wished I hadn't started it. There have been times this caused me a significant decline in my mental health. But I think this might have been the most worthwhile use of my energy so far at balena. We're only 8 months into running this programme, but I'm hearing good feedback, I'm seeing new joiners finding their way inside balena with more ease, and the momentum is growing. Over the next 12 months I want the whole residency programme to be run and developed by the whole company, without any dependence upon me. And I want to see it to be expanded, to cover cases we haven't explored yet: such as people joining balena only to do a residency, while they build a product on balena, and then go seek funding for it. Like a product incubator. I'd love to see that!

Personal Growth

My technical skills are still growing all the time. I had never used Docker before I joined balena, so I've always had a steep learning curve here, and that's fine with me. I'm constantly getting myself involved in things I don't know how to do, and then working with others to do them. So naturally my technical skills continue to evolve.
But I'm actually more interested in how my non-technical skills are growing. Here's some things I've observed:

sunk cost and Occam's razor

When I am excited about an idea, like a toddler with a new crayon, I just have to go and work with it. My brain is obsessed and I'll get no inner peace until I've scratched the itch to hack on the idea. That doesn't mean I rush in without thinking it through - that happens all the time I cannot physically hack on it. My brain will be whirring through designs and solving problems every moment that I am not asleep. And then after a while I will have something I want to share with others. In the past when those people then gave me feedback, sometimes it would contain views that my thing was too complicated. Maybe they would question why some, or all, of it needed to be there at all. They would question if there was a "need" for something I had made.

On several of these occasions I experienced an almost "out of body" experience where I saw myself explaining why something was in my product, and realised I was defending it because of emotional reasons. I'd spent time making it. I remembered the hard work to get it to function. I had imagined a future user finding it useful and being happy. I had emotionally motivated reasoning for the thing, not a logical reason for the thing. A sunk cost.

I still do this, to a degree. But I am a LOT better at noticing when this is happening, and correcting myself. I try to implement the simplest thing, not the most configurable thing. And I've also noticed that I'm noticing where things can be simplified more often in other places within balena. For instance it occurred to me that checking references as part of the hiring process took up a lot of people's time (not mine) and never actually contributed to our decision to hire or not. So I advocated for us to stop doing that. I love the fact I can get involved anywhere in the company, advocate for change and that change happens if when we all logically agree, not because I am or am not more senior than someone else. :)

Assuming positive intent

This is another one I continue to get better at, but with more to do: assuming that someone's behaviour comes from a place of positive intent, and any aspects that seem negative are communicating they need more help.

There's something about my upbringing, or previous career experience, or both, that makes my brain sometimes jump to negative conclusions when someone does something I disagree with. Especially so if I am really convinced it's a behaviour that is counter to the culture we're trying to grow at balena. But by talking these events occur I make sure I talk them through with someone else, who's ability to see positive intent is more honed than mine (I'm looking at you Alison, Chris and Andrew) and actively try to challenge my own thoughts about the person and what happened.

More and more I am noticing my own thoughts can initially seize upon an event negatively, and then catch hold of themselves and course correct. I'm still not perfect, but I'm making significant progress here.

Optimise for fun!

I say this a lot, and my certainty that it's THE most important thing to focus on in work and life, is all the more resolute. Just as I am sure that only happy children learn to their potential, only happy people build products to their potential. I think there are only a very few things that are not made better by having fun whilst doing them (the dentist is NOT a fun place...). At balena hiring should be fun. Testing things should be fun. Meetings should be fun.

In my personal life I am determined that fun is priority numbers 1, 2, 3 and 4. Everything else is low down the list. My children's learning must be fun. There is a phrase we have at home: "it's fun, or it's not done" and both of my children are empowered to stop doing anything they find not fun. Same goes for me. :)
When we clean the house, we put loud music on, sing loudly, dance like nobody is watching and clean at the same time. When we wash the car, we have a hosepipe fight and giggle about spraying the hose over next door's hedge. Bedtime is spent enjoying reading stories together, the love of language, giggling at characters until we feel sleepy enough to sleep. It's fun, or it's not done.

What's next?

Well, I can't predict the future, so I don't know for sure. But a bit of staring into the void leads me to believe my path in the next 12 months looks something like:

explore the boundaries of what we can do with the labs residency
continue to push for improvements to the blocks developer experience
get more involved in generating outreach content to communicate the balena culture
experiment with ways of working more and more in the open
MORE FUN!!!!!

Lightweight .NET5 containers on balena

Phil Wilson — Sat, 30 Jan 2021 17:14:16 +0000

Before joining balena I was a pure .NET guy. I've been coding .NET since it was released in 2002, back when I was a university student actively avoiding lectures on ALGOL.

Joining balena saw me take a break from .NET and focus my energy on learning the balena stack and improving my docker, python and node.js skills. Lately, however, I've had the itch for .NET again, mostly so that I can play with .NET5. I had dabbled with Blazor in my balenaLocating project but hadn't paid very much attention to the docker image size. I was so focused on releasing my first ground-up project, which was all my own code, that I merely used a multi-stage dockerfile and left it at that. The result is a ~300Mb image, for a single page webapp that doesn't do a whole lot.

Surely we can do better.

The plan

Since the, soon to be released, version 2 of the browser block has an API to dynamically configure it - I wanted to make a remote control for it. I'll use Blazor on .NET5, and explore some of the options to get the image size down to as small as possible.

Let's go!

Setting a baseline

I knocked up a quick Blazor page which sends some API calls to the browser block and displays the results. Nothing complicated. Building that project:

⚡ phil@DESKTOP-I18LU69  C:\Source\Balena_Playground\BrowserRemoteControl                                                                                                 [10:06]
❯ dotnet build
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.   

  Determining projects to restore...
  All projects are up-to-date for restore.
  BrowserRemoteControl -> C:\Source\Balena_Playground\BrowserRemoteControl\bin\Debug\net5.0\BrowserRemoteControl.dll
  BrowserRemoteControl -> C:\Source\Balena_Playground\BrowserRemoteControl\bin\Debug\net5.0\BrowserRemoteControl.Views.dll

Build succeeded.        
    0 Warning(s)        
    0 Error(s)

Time Elapsed 00:00:10.16

resulted in a HUUUUUUUUUUGE 1Mb executable. :D

And then I did a bog basic, single stage dockerfile to build the project and push it to my balena app:

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-dotnet:5.0-sdk-buster-build as build

WORKDIR /usr/src/app
COPY ./src/* /usr/src/app/

RUN dotnet restore

ENTRYPOINT  ["dotnet", "BrowserRemoteControl.dll"]

whoa!!!!!

[Info]     Uploading images
[Success]  Successfully uploaded images
[Info]     Built on x64_01
[Success]  Release successfully created!
[Info]     Release: b15a7405a5be9ab5df4081bdc34d0678 (id: 1678274)
[Info]     ┌─────────┬────────────┬────────────┐
[Info]     │ Service │ Image Size │ Build Time │
[Info]     ├─────────┼────────────┼────────────┤
[Info]     │ main    │ 1.04 GB    │ 17 seconds │
[Info]     └─────────┴────────────┴────────────┘
[Info]     Build finished in 1 minute, 5 seconds
                            \
                             \
                              \\
                               \\
                                >\/7
                            _.-(6'  \
                           (=___._/` \
                                )  \ |
                               /   / |
                              /    > /
                             j    < _\
                         _.-' :      ``.
                         \ r=._\        `.
                        <`\\_  \         .`-.
                         \ r-7  `-. ._  ' .  `\
                          \`,      `-.`7  7)   )
                           \/         \|  \'  / `-._
                                      ||    .'
                                       \\  (
                                        >\  >
                                    ,.-' >.'
                                   <.'_.''
                                     <'
⚡ phil@DESKTOP-I18LU69  C:\Source\Balena_Playground\BrowserRemoteControl 

1Gb....! That's because I'm pulling the WHOLE .NET5 SDK, which I don't need just to run my little executable.

Multistage dockerfile

First port of call is a multi-stage dockerfile. We don't need all of the build dependencies to run the .NET executable once it's built. So we can build it, and then copy the result into a slimmer run image:

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-dotnet:5.0-sdk-buster-build as build

WORKDIR /usr/src/app
COPY ./src/* /usr/src/app/

RUN dotnet restore

RUN dotnet publish -c Release -o /usr/src/app/publish

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-dotnet:5.0-aspnet-run
WORKDIR /app
COPY --from=build /usr/src/app/publish .

ENTRYPOINT  ["dotnet", "BrowserRemoteControl.dll"]

and the result is:

[Success]  Release successfully created!
[Info]     Release: 09beeb66c9be98cc10f362c14a4519c0 (id: 1678468)
[Info]     ┌─────────┬────────────┬────────────┬────────────┐
[Info]     │ Service │ Image Size │ Delta Size │ Build Time │
[Info]     ├─────────┼────────────┼────────────┼────────────┤
[Info]     │ main    │ 280.44 MB  │ 666.39 KB  │ 1 second   │
[Info]     └─────────┴────────────┴────────────┴────────────┘
[Info]     Build finished in 56 seconds

OK! So we're down to 280Mb just by using a multi-stage dockerfile and not keeping all the build dependencies. This is on par with my previous Blazor project....but there's more to be done. Let's play with an Alpine image.

Moving the Alpine

Alpine is a lightweight linux distribution. We can use it to make smaller images for our containers, but the onus is pushed onto the developer to make sure all the runtime dependencies are there. For this project, I need to make sure the .NET5 runtime deps are installed:

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-dotnet:5.0-sdk-buster-build as build

WORKDIR /usr/src/app
COPY ./src/* /usr/src/app/

RUN dotnet restore --runtime linux-musl-x64

RUN dotnet publish -r linux-musl-x64 -p:PublishSingleFile=true -c Release -o /usr/src/app/publish

FROM balenalib/%%BALENA_MACHINE_NAME%%-alpine as run

RUN install_packages ca-certificates \
        krb5-libs \
        libgcc \
        libintl \
        libssl1.1 \
        libstdc++ \
        zlib

ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT 1
ENV ASPNETCORE_URLS=http://+:80
ENV DOTNET_RUNNING_IN_CONTAINER=true
WORKDIR /app
COPY --from=build /usr/src/app/publish .

ENTRYPOINT  ["./BrowserRemoteControl"]

You can see there, that I'm using an Alpine image and using install_packages to bring in the .NET runtime dependencies. Then I do a couple of ENV statements to set the container up for running an AspNetCore HTTP server (Kestrel) and run the compiled executable.

And the image size? Well:

[Success]  Release successfully created!
[Info]     Release: ce1f65a85e457b4c8a116cbc933262b9 (id: 1678500)
[Info]     ┌─────────┬────────────┬────────────┬────────────┐
[Info]     │ Service │ Image Size │ Delta Size │ Build Time │
[Info]     ├─────────┼────────────┼────────────┼────────────┤
[Info]     │ main    │ 157.69 MB  │ 0 bytes    │ 1 second   │
[Info]     └─────────┴────────────┴────────────┴────────────┘
[Info]     Build finished in 38 seconds

157Mb! That's great.
...
But there's even more.

.NET publishing optimisations

.NET now has a few tricks up it's sleeve to get your image size down even smaller. These are:

-p:PublishSingleFile=true

Create a single file distributable, rather than an exe and a bunch of DLL dependencies

--self-contained true

Package the .NET runtime in with the executable, so that we don't need a runtime to be installed. Note this was also in the Alpine step above, but I've explained it here. :)

-r linux-musl-x64

The self-contained file needs to target a device architecture (otherwise it would need to target them all and waste space). I'm running this experiment on my Intel NUC, so I'm targeting x64, and since it's an Alpine image I need to target the musl C library. The choice of RIDs (runtime identifies) can be found here.

-p:PublishTrimmed=True

Here's the magic part: bundle trimming. This step causes the source to be analysed (it takes a few minutes) and unnecessary .NET framework components removed from the published executable.

-p:TrimMode=Link

More magic. In a nutshell, without this parameter the resulting executable will have the whole of a framework assembly, even if only a part of it is being used. With this option, each member of each assembly is assessed, and only those being referenced will be included. This worked find for me, but I have seen reports of runtime issues - so YMMV. Not setting this for my project causes a difference of ~10MB, so do some testing or just err on the side of caution and leave this optimisation out.

Final result

So now the publish line in my dockerfile from above looks like this:

RUN dotnet publish -p:PublishSingleFile=true -r linux-musl-x64 --self-contained true -p:PublishTrimmed=True -p:TrimMode=Link  -c Release -o /usr/src/app/publish

which gives me a final image size of:

[Success]  Release successfully created!
[Info]     Release: 621d73fa5676e5924f7a885726bc20d5 (id: 1678525)
[Info]     ┌─────────┬────────────┬────────────┬────────────┐
[Info]     │ Service │ Image Size │ Delta Size │ Build Time │
[Info]     ├─────────┼────────────┼────────────┼────────────┤
[Info]     │ main    │ 95.06 MB   │ 23.78 MB   │ 48 seconds │
[Info]     └─────────┴────────────┴────────────┴────────────┘
[Info]     Build finished in 1 minute, 30 seconds

95Mb down from the baseline of 1Gb. Sweet!

So what?

So, if you're thinking about using .NET in docker, including a balena app, then take a look into multi-stage Alpine dockerfiles with some publish optimisation. You can pack quite a lot of functionality into a pretty small image.

Happy hacking!

Pandemic brain

Phil Wilson — Sun, 24 Jan 2021 12:06:00 +0000

I joined balena from a startup company where I was the CTO, and the technical architect....and the lead developer.....and technical pre-sales....and directly involved with convincing the investors to keep investing to keep the company afloat. Back then I couldn't think long term. I had to fix that bug to keep the customer happy else they refused to pay. I had to design and develop yet another solution to yet another use case that the customer HAD to have, or they would refuse to pay. The very most I could ever think about, was getting through the next day.

When I joined balena it took me at least 6 months to allow my brain to think long term. balena practice "short term pain for long term gain", or let's do the right thing and solve for the future rather than just the quick win that we have to re-fix later. Several times I would see a problem and propose a quick fix, as was my conditioned mentality, only to be told the real solution was a much bigger piece of work. I needed patience, and I needed long-term thinking.

Healing and unlearning

With enough time and the empathetic guidance of great colleagues I was able to let go of that need to fix the now. I focused my attention on some long term pieces of work such as balenaBlocks, and found/made my place in the company mission.

A return to short-term thinking

However, recently I have realised I've reverted back to old habits. Twice in the past couple of weeks those same empathic colleagues have had to point out that I'm trying to solve a problem now, not build the product that solves that and many other problems later. So why has this happened?

Pandemic mentality

After giving it some thought, I realised that the current world situation has caused me to think in short timeframes. On the Sunday the prime minister says the children will go to school. On the Monday evening he closes all the schools. One day my wife's business is running. The next day it has to close again. One day someone I love is healthy. The next day they are not.

My brain is back to just thinking about 1 day at a time. Actually sometimes it's been as granular as thinking about the next couple of hours. How do I have that meeting, whilst helping two children home school? How do I concentrate on the bug I'm figuring out, when my elderly neighbours are unable to get a food delivery?

A need for quick wins

It's not just me. I've heard a number of colleagues say "I need a quick win" recently. Dopamine is in short supply after multiple national lockdowns and social isolation. Sources of fun have reduced: the pubs are closed, the shops are shut, leisure activities are now not allowed. I almost can't remember taking the children swimming. Long gone are the days of wandering through a town and spontaneously stopping somewhere for some food. Holidays...ha!

I'm not at all surprised that my brain is jumping to short term yay over short term pain. I've plenty of pain. My brain is swimming in it. I guess it's a form of bounded rationality: something seems like the right thing to do, when my mentality is about survival in the now.

And so, what to do?

Step one is done: I've reflect and noticed the thought patterns. I can't change the situation I'm in, so the only avenue for progress is to try and periodically remind myself of the goal and how I participate with my daily work. balena do a good job of communicating the mission, and have lately worked hard to break it down into multiple sagas. The hub is one of those sagas, and I know how to add to that story. I need to make sure I keep talking to colleagues, and recount the sagas. Our tribal ancestors used gatherings around the fire to recount stories and jointly sing songs. That practice of story telling and syncing keeps the tribe together, and deepens the impression of the future they are building.

We also need to "find the fun". It's a phrase I say to my children so often they now eyeroll at it. But it's true: no day is perfect. Perfect isn't real. But whatever the day brings, there is fun to be found. Rain means jumping in puddles. A lockdown means we build a slide in the garden.

There is no reason that work can't or shouldn't be fun. In fact, I think it's an imperative. People shouldn't need to find a quick win for that dopamine hit. We should make the time to laugh together and turn the short term pain into part of the game. If I had a big mound of shit to dig, the worst thing I could do is moan about it. Instead I would need to turn it into a game. Let's compete over who can dig the most shit in a day. Let's throw the shit into the wheelbarrow from the top of the pile. Let's sing silly songs about digging shit, do some dad dancing and make a shit castle complete with flag. Let's turn our spades into shit sledges.

If we find a way to smile and laugh while we dig, one day there will be no more shit.

Peace out.

balena: 12 months in

Phil Wilson — Wed, 20 Jan 2021 16:53:34 +0000

In January 2020 I joined balena as a Hardware Hacker in Residence or HHR as balena call them. I joined a group of other HHRs in, what is now known as, the balenaLabs team and started on my balena journey. My first few weeks were exciting and daunting in equal measure...and then 2020 happened. Here's a look back on my first 12 months at balena.

Some background

During my career I've worked for big corporations such as IBM and CGI, and have been embedded into Microsoft development teams. I've worked on Space, SatComm, UK Defence, National Security, Telecoms and Energy projects. I started working on IOT projects back when most people (in the UK, at least) hadn't heard the term. Back then I had to give those "20 billion devices by the year..." presentations and answer countless questions about internet connected fridges from loud men in bright trousers whom people still referred to as "Major".

So I've been around a bit and experienced lots of different ways of working. I wasn't one of the people who had to learn how to do remote working in 2020 - as I've been a remote worker since my first son was born in 2011.

However, nothing in my career before 2020 prepared me for what it's like to work at balena. Here's why:

Globally asynchronous

The first thing that struck me when I joined balena was that there was always someone online working and chatting. Although I'd worked on projects that spanned timezones, I'd never worked somewhere that spanned ALL the timezones. I was used to work communication stopping by about 6PM, so I never really had to think about notifications when I wasn't working. Back then I needed to see emails immediately, and reply ASAP, or else my peers would assume I'm not working, not dedicated, undeserving of a good annual review. It took me a good month to fully realise that balena meant it when they said "you don't need to answer everything straight away. We expect you to be async and reply whenever you can.". What that means is that I can turn off all my notifications. Nothing beeps at me any more. I don't constantly check emails or messages. I'm trusted to work when it fits in with my life, and to answer questions when it suits me and my brain.

The great benefit of this global team, though, is that there is almost always someone around to chat to, or hang out while we work. Often, during periods of national lockdown, I'll tend to family during the day and catch up on work in the evening, and hang out with some U.S colleagues while I do.

Organisation

The next thing I needed to adapt to, was the way balena organises itself. No longer was I siloed into a given team, or an industry, or even a role. Sure I am a Hardware Hacker, and I tend to hang out in the labs, but literally nothing stops me from attending any meeting or getting involved with any piece of work technical or otherwise. All work is conducted in the open, so I can see all conversations, and contribute to anything I feel able.

Nobody tells me what to do, and nobody "manages" me. We make huge efforts to make sure everyone knows and shares the mission, and then finds ways to contribute towards this. We collect together in brainstorm and checkin meetings, share our ideas and progress, and get genuinely excited about each others work.

Engineer-driven Support

Nope, we don't do support like most other companies either. At balena all the technical people share support. We all do a few shifts per week, and we do this so that everyone gets to help customers, hear about issues and pain points, and dig into other bits of the stack which we might not otherwise touch. I'll be honest: support isn't my favourite part of the job, but it can be rewarding and does push me to learn more about system as a whole. This type of support puts the team into the user's shoes, and drives us to continuously make the product better and further reduce the friction of IOT.

Culture

This is my favourite thing about balena. The people who work here are SO clever and so fun. Work meetings used to be the worst parts of my week. At balena, they are genuinely some of the best. We make sure we have fun together, because making work fun stops it feeling like work. We hack projects together. We play games together. Even our brainstorm meetings are a game.

You can get a window into how we chill together by watching our IOT Happy Hour on youtube:

First 12 months?

Well what has it been like? Amazing. Genuinely. Despite a crazy global situation in 2020, for me it was a great year professionally. I met and got to know amazing people who have become close friends. I've learned a shed load about linux, docker, single board computers, node.js, python and lots more. I've written blog posts, appeared on the IOT Happy Hour (--^) and M.C'ed release parties where we work live on YouTube and release a new feature. I've released labs projects and put apps onto our hub.

For the first time in my professional life, I'm REALLY excited about the year to come. Let's go!