More progress milling PCB's

In my latest attempt with 0.4mm end mills, I was able to achieve a beautiful etch. However, I encountered frequent breakages of the bits, costing nearly £4 each, which was frustrating. Upon reflection, I realized that the spindle speed was too slow. To address this issue, I have ordered a variety of bits from Ali Express and plan to conduct further testing in a few weeks.

Etched pcb traces using 0.4mm end mill.

In the meantime, I decided to try a new approach by purchasing v bits specifically designed for PCB manufacturing. I utilized a 10 degree 1mm bit for engraving and employed the profile toolpath with the outside vector, offsetting it by a few tenths of a millimeter. This method proved to be very successful, and I used an 0.8mm end mill for the holes and a 2mm end mill for the mounting holes (although I made a classic mistake by confusing radius and diameter when cutting out the board). The end result was my first fully functional board, which was more than adequate and would work well for double-sided boards. However, the settings for the 0.8mm still need work, as the cutting process is currently painfully slow. Despite this, I am thrilled with the excellent progress I have made so far.

The board? A very simple breakout for a buck converter, exactly the kind of basic utility pcb that this process will be invaluable for.

My First Attempt at Milling a PCB on a Mini CNC Machine

TLDR - so far good enough for single sided boards. Need to refine process for double sided.

For over a decade, I've been interested in milling printed circuit boards (PCBs) using a CNC machine. Chemical etching can be messy, and ordering from manufacturers can be a hassle, so I was excited to finally try it out at South London Makerspace with the help of Andy and Kyle.

To start, Andy had already purchased a set of "PCB" tools with end mills ranging from 0.8mm to 3mm on a 1/8 collet, as well as a set of 3.175mm V bits. I designed my PCB in KiCad, adjusting the pad sizes as large as possible, the clearance to 0.5mm and the minimum track width to 1mm and then exported the file as an SVG.

In InkScape, I created a negative of the PCB by filling the white space with black and deleting all other layers. Then, I used VCarve to generate the GCode for the CNC, selecting the Pocket ToolPath function and adjusting the cut depth to 0.04mm. For tools I selected an 0.8mm end mill and a v-bit. To offset the path and leave more trace/pad, I added a pocket allowance of 0.2mm for the v-bit path. Kyle suggested we run the calculation, but then ignore the end mill clearance, only running the v-bit path, and this worked well and significantly reduced job time. For the holes I adjusted the cut depth to 1.6mm and used the 0.8mm end mill.

To fix the blank PCB to acrylic, I used masking tape and super glue. Masking tape is applied to both the board the acrylic, and you then glue them together. The test cuts went well, but I found that the v-bit was either cutting too deep for double-sided boards or left nasty burrs when scratching the copper. Essentially the depth of the trace cutting was determined by my Z axis touch off. However, the holes drilled well and were good enough.

Overall, it was a successful first attempt, and I plan to refine the process by using 0.4mm end mills for cleaner cuts with less material loss. I'll keep you updated on my progress!

Learning, a Team Game

I have just finished week 5 of the software bootcamp at Makers. Week 5 is engineering project 1, where we work in teams to create a simple implementation of a holiday home booking site. It was clear from the beginning that none of us would be troubling airbnb this week —this task was all about learning to make software as a team. In fact, this task was all about teams and people.

I have spent most of my adult life working in arts and music. I’ve had lots of different roles, and have been lucky enough to be creative in most of them. As we move through this bootcamp, I’ve started to really interrogate my previous experience of working with others, and I began to realise that while I had worked a lot with groups, I wasn’t so sure that I had worked a lot in teams. The group work I have done has normally been quite hierarchical — and in the arts its normally clear who is in charge — and if not its often thrashed out until it is obvious. So either I am serving someone else’s vision, or I they are serving my vision. And it’s normally the case that someone has the final say, and others defer to that. I am of course generalising, but it rings true to me. Further, I have made a lot of projects — and I have been very outcome focused, to the extent that outcome and deadline were more important than anything else. Often I am the only person working on a project — so I have complete control (ah control, hello old friend), or when I am working with others I am either being paid, or I am paying someone, or I have a ‘Lead Artist’ moniker, or they do — all of which instantly brings in the hierarchy. As I began to think this through a few weeks ago I came to realise that I had a bit of a control problem — and I needed to practice letting go else I was not going to grow. I also had a large ego connection with finishing things at whatever cost, and also with ‘winning’, again often at any cost and this has led to some very unhealthy behaviour including many many all nighters on projects, and behaving badly to team members during hackathons (we did win, and I did apologise for being a domineering misogynistic patriarchal patronising a***hole — but surely better that I am just not that to start with?). So I made a conscious decision a few weeks ago to try and live some of what Dana has been encouraging us to do, and lean into the uncomfortable. I am going to try and put aside control, winning at any cost and my habit of thinking I know best, and instead attempt to listen more, be open to other ways of doing, and try and experience what it really is to work in a team — to work together, for all hands to be on the job, and to communicate well and openly. I have been putting this in practice during pairing over the last few weeks, but this was the big one, a team project. Time to get uncomfortable and to learn something. And to be okay with not knowing what I was going to learn or what success was going to look like.

The Team Jaguar Logo (TM)

So Gawain — how was it?

Thanks for asking — bloody hard! But also absolutely amazing. I was placed in a team by a human, or an algorithm, or a combination of both — and I can honestly say after an intense week together I could not of asked for a more open, honest, kind, thoughtful, brave and generous group. Go Jaguars!! From the very beginning we were able to talk openly about who we were and what we wanted to get out of the week. We then kind of stumbled on, making mistakes, talking about them, and being relentlessly honest in our standups and retros. There were moments where I had no idea how we move forward, and then someone would step in with a gem. There were times when we did not feel like a team — where it felt like we had all disappeared into our own comfort zones. There were moments where I despaired — honestly, that was the control freak in me. There were times when others needed my support, and I was not able or was not willing to give it. There were times when I needed support and it wasn’t there. There were times when I wondered aloud to a friend or a colleague about problems— and then I found the grace and courage to say it to the whole team, publicly and transparently, but also, I hope with empathy and emotional intelligence. I had a really tough day on Wednesday, and at the end of the day my team stopped what they were doing and really took the time to check that I was alright. There were many moments where I was completely stuck, and someone stepped in and suddenly I went from “I have no idea what to do” to bashing out 3 tickets in an hour. We did not make the best airbnb clone this week, but I really learned about people and being a team, and I hope the other Jaguars also felt this.

I’ve learned this week that we’re all insecure and insecurity manifests very differently. Sometimes it looks like being in charge or being in control with special rules, and ways of doing things, monitoring behaviour. People doing things like we said we would. Sometimes it looks like working really hard, getting on with things, getting things finished. Sometimes it looks like downing tools and childishly stopping work. Sometimes it looks like talking and making your voice really heard. Sometimes it looks like hushing our voices and not speaking up. Not doing. Not taking part. Sometimes it looks like not letting someone have a go at something or go the wrong way for a while. Sometimes that ‘wrong way’ is actually a better way (I’m a big one for a ‘right way’)

Most importantly I’ve learned how much more powerful we are as a team. I really felt the most together at the end. We had been through something and we had all been seen. We had invested in each other — and were now ready to work as one. Five people working together is always going to be more powerful than four people led by one. It may have taken the week to get to, but it was more than worth it. Team Jaguar — thankyou so much. My only regret is that we are not a team next week as we have formed a very effective unit. I really hope we get to do something together again.

OOP and Large Format Studios

I am currently 5 weeks into a 12 weeks software bootcamp with Makers. This past week I have been thinking a lot about the concept of Object Orientated Programming (OOP) and I’ve been having a lot of revelations. One of them has been the similarities between the concept of OOP and the use and understanding of a recording studio — particularly a large format old fashioned studio.

I appreciate this blog may have a niche market. But it’s helping me get my head around things, so I’m going to get on with it.

A large SSL mixing desk

Recording studios and large format mixing desks are very intimidating in their complexity, and if approached only considering their wholeness, it can be very difficult to even begin to get a handle on it. The answer is to break it down into its components. If we take an 60+ channel SSL desk for example, it is physically huge, and it is literally covered in buttons and knobs. The key to getting your head around one is to understand that every channel is essentially the same. If you can get you head around that, then you have instantly reduced the number of things to get your head around from 60 to 1. Each of these channels receives one audio signal and can give it back to you several times at at several points. The sound travels through the channel as electricity, and on the way you are given the choice to divert the sound to other parts of the studio, and how much to divert. You are also able to shape the tone of the sound using an equalizer, and alter it’s dynamics using a compressor. Lastly there is a main fader which gives you the level going to the main mix.

So if we break it down it becomes a lot easier to understand.

Inputs (either/or)

• Line in

• Mic in

Outputs

• Aux busses

• Groups

• Main bus

Ways to alter the sound within the channel

• Tone (Equalisation)

• Dynamics (Compressor)

A (much) younger me at the controls

The complexity comes from the many — there are many of the same channel. The complexity also comes from these many outputs as we can use them to send the sound elsewhere — and this is the bit that is really exciting me when I am thinking about OOP. The thing is you see, despite all the complexity and cleverness, whatever receives that sound knows absolutely nothing about it. I as a human being have decided to plug it into an effects unit for example — lets pick something iconic, an Eventide H3000 — but the Eventide has absolutely no knowledge of what it is receiving. So we have two things with massive complexity interacting to do something wonderful, but neither knows anything about the other. It is up to me as the engineer to make sure that I adhere to the specification at the output and input stage — and then they are free to do their job. In this example both the pieces of equipment are literally objects — they exist in the real world. But the point is that they interact with very simple interfaces and a short set of rules as level and impedance, and have no knowledge about what’s going on with each other. Very high level and very abstract. They each then have a user interface which is designed with the recording engineer in mind — this is a level lower and expects some knowledge, but is still an abstraction — with a handful of controls hiding most of the complexity. Lastly then you have how they actually work, which is not in the domain of the recording engineer (or not necessarily).

And essentially, that is the key to getting your head around a studio — you have many pieces of equipment (objects) — some of them grouped together (like in a mixing desk). They are connected with very simple connections which have simple rules (I’m thinking these are like parameters or exposed variables). Most of these are audio connections. Sometimes there is also some simple control such as MIDI or SMPTE. There are some controls that change things (I’m thinking like methods in a class). And then there is how they actually work — which, to be honest, is normally not thought about that much and is the business of the designers and makers of the equipment, except to part us with our cash because they use some tech-de-jour and essentially saw us coming.

So long as the inputs and outputs are simple and adhere to convention, and the controls are understandable and useful, then that is enough. From this very complicated things can then be built and wonderful things achieved.

I have got to the end of this blog and am still happy that this kind of works as an analogy (for me at least) — would love to hear what you think and if it’s making sense to you. I’m off to read more about OOP and get excited.

The path is not yet laid

Doing something like Makers Academy is a commitment to change. For me it’s about changing career — a path towards a future where writing software is the core of my working life. I still don’t really know what that will look like, but I realise that I had quite firm ideas about how I would get there, and when I started to struggle it was disorientating, I was losing control over the narrative, and it’s taken me a couple of weeks to re-orientate myself.

Here are my struggles:

Taught sessions.

I had such a positive first week, that when I had one taught session that didn’t meet the pedestal I had personally place Makers on, I basically couldn’t cope and it led to a bit of a spiral. Makers continually tell us that we are responsible for our learning and path — but I had delegated all that responsibility to the teaching. And teaching is hard — I know, I’ve done some — it is never going to suit all the people all of the time. I reflected on this with the lead coach, with my peer group and with the coach in question, and I also reflected on it personally and I realise that it has brought up much for me. Yes there is responsibility on Makers and the coaches — and I will stress that in discussing this I was left in no question of this — it was instantly palpable and I was able to feedback properly with no defensiveness on their part. But there is also responsibility on me. Coding is a career of learning — and I need to know how I learn and what I need in order that I can succeed and continue to succeed.

Working with others

I have come from a career as a full time artist and musician. I am not in any way used to working with others in the way that we are on this course, nor am I used to routine and boundaried work in this way. I have to say I have loved pairing and really believe in it, but also, working closely with other people is hard. It’s hard because of me and it’s hard because of them. We’re all complex human beings with good and bad days and it hasn’t always been easy. I’ve come to realise that this is perhaps one of the greatest things about this course. Learning while in a structure that mirrors the profession. To be able to have positive, negative and indifferent experiences of working with others while scaffolded in a safe environment is frankly priceless. I am going to be working in teams and sometimes I will get it wrong and I will be working in teams and sometimes someone else will get it wrong. To be able to model this, learn from it and gain that experience is so powerful. Hard, but powerful — and my cohort are, frankly, incredible — so if it’s not always easy with them, then any skills I can learn now will really help me out in the wild.

Managing my own learning

In many ways this is similar to most of the course — learning how to manage your own learning is as much a personal journey as all of it. Ideally we have to work out who we are and what works for us. Finally I think I’m getting it. There is a broadly signposted journey that we are all on together, but we should be exploring and finding our own ways there. Sometimes this looks like being taught, sometimes this looks like pairing, sometimes this looks like a conversation and sometimes this looks like working on our own. There is no right way. Am I learning? Am I having fun? Am I a better developer than yesterday? My blockers are weird and uniquely mine. A childhood confusion with grammar led to me feeling completely lost with diagramming for more than a week until I paired with a friend and we edged forward. This unblocked me. And then someone else suggested a less linear approach and suddenly I’m flying. The other week I took the weekend challenge off on a totally tangential route — got very little of the actual task done, but had loads of fun and learnt a lot. This experience is rooted in learning — not in curriculum.

So I find myself challenged and changed. The course remains incredible, but I am growing in areas I didn’t know I needed to — and that feels unfamiliar, but also wonderful. The path I am on will only be laid when I reach the end, and frankly, I hope I never do.

To learning…

You’re Already There

I’m on a 12 week software bootcamp run by Makers Academy and this is my reflective blog on the experience. This past few days I’ve been thinking a lot about the act of learning, being taught, teaching and growth.

If what we are learning is a city of knowledge, then it can be tempting to view an experience like this bootcamp like a version of the famous London taxi drivers knowledge. In order to be allowed to be licensed as a black cab driver in London you have to learn every single street. I mean. Every. Single. Street.

There are thousands of streets and landmarks within a six mile radius of Charing Cross. Anyone who wants to drive an iconic London cab must memorize them all: the Knowledge of London.

Its incredibly impressive — and in many ways, despite the hugeness of this task, there is also something very knowable about this path to success — when I know all the stuff, then I’m there.

Taken as a metaphor for learning to be a software developer, it starts to look a bit problematic however. What if I want to work in a different area than the one I learn in for example? Reflecting on this I think maybe it’s more helpful that we get really good at reading a map. Then we have learned the skills we need to make our way anywhere — including places we haven’t thought of yet. And while knowing all the stuff brings a confidence with it, so does knowing how to find your way.

But software development can also be very creative. What if I want to work in new areas. What if I want to make my own map? Reading existing maps is really useful, but there is also some lower level skills needed here too. Compass reading, topography — and writing it down — mapping new places so others can follow you. I was thinking about how much I have changed even in a week on this bootcamp. I used to fire solutions at problems until they went away. Now I study the error messages and follow a procedure. Consequently I am much more certain of why something works and of how I got somewhere.

Process is emerging as a key thing to note and build. As I was walking through London with one of my kids yesterday I remembered stories I’ve been told of characters leaving a trail as they enter an unfamiliar wood, so they can follow it back — and I wondered if in some way TDD provides me with a path to follow. The satisfaction not just of something working, but of knowing why it works.

I’ve been really struck so far at Makers by the style of leadership. There is a total absence of expert energy. Instead there is a humble openness and confidence to the coaching. I feel that me and my cohort are really listened to and our thoughts and ideas allowed to be heard and acted on. Nothing is wrong or right, and I feel like a real effort is made in trying to understand our emerging process. If the coaches are the Senior Devs in the team I am currently in, then this is something I would really like to learn from as I progress.

There was a brilliant moment when pairing on Wednesday when we came across a resource that said “Error messages are good”. I’m not sure I was really quite ready to hear that at the time, so I responded with an eye roll and some nervous laughter. But actually — in this nugget is perhaps one of the most important things I’ve learned this week. It’s all about the error. What’s it trying to say to me? How do I fix it? I am starting to learn that I have the best experience when I stay really close to this — just fix the error in front of me. When I lapse into trying to address several things at once a couple of things happen. One I move into assumption — I don’t actually know if there is an issue beyond the one error I am supposed to be addressing and second I become overwhelmed very quickly as I am not able to see the consequences of the many changes I am making. So just address the error message. One at a time. Step by step.

So error messages teach us something, and this got me thinking about the errors I make as a person. They teach me something too. As I type this I’m a little overwhelmed by the hugeness of this. I’m 43 years old, and for most of my life I have been told that I can learn from my mistakes, I’ve liked social media posts that say things like “your mistakes are your teacher” but I’m not sure I have really managed to get with it yet. Maybe change is coming. What if the mistakes I made where there to allow me to incrementally change — as the messages in the terminal allow me to move forward in tiny steps. One to think on…

Which leads me to think about how to react to the curriculum, my peers progress, my progress and struggles and growth generally. We have been told there is far too much resource available to us on the course to do it all. And anyway, if that resource is the taxi drivers knowledge of London, it doesn’t serve us well if we end up in Coventry anyway. So how would it be if each step of the course means different things to different people depending on where they are at. That our progress through the course is also teaching us — helping us to see where we are and what we need to do next.

So what is this experience? Where are we going? It’s a path to being a software developer obviously. I wonder however if we’re being encouraged to see that we are already there. I started this blog thinking about how to be a Software Developer. Maybe instead I am a Software Developer learning how to be.

Made with only the finest ingredients

I’m learning to write code in Ruby using a method called Test Driven Development, or TDD for short. The principle, as I understand it, is that the software plan is boiled down to the smallest possible problems. From each problem we are then instructed to follow a very prescriptive method that involves trying, and failing, to do what you want to do in real time code (we’re using irb), replicating this in an automated test using rspec, running the test and looking at the errors. We then use these errors to guide the writing of the simplest possible solution to pass this test and then we start again with the next problem.

The temptation is to skip tests — every time I see a step there’s a voice in my head that says “Nah — come on, you can miss the irb step, right?” or “really do I have to do a unit test and a feature test — surely just a feature test would do?”

Despite this my pair and I persevered (this course is the opposite of a super hero movie, I never work alone), and what I noticed was that despite the feeling of moving slowly by following these steps, we were actually making really good progress — and really importantly we were understanding why we were getting places, and making few mistakes. When our process did differ from the “answer” (“answer” is in itself a problematic concept, one for another blog), we understood how and why, and were able to make informed decisions whether to refactor to match the tutorial, or to stay with our different version and why we preferred it.

Reflecting on all of this I thought about food, food preparation and dining. If we were in the business of learning to cook, then what kind of chef’s do we aspire to be? Everyone on this course is looking to change career, and heavily invested in it. So this isn’t some home cooking/hobby vibe. We need to think fine dining — people will be paying us money for our code. In that context I thought about the care a chef puts in — you would examine every ingredient, every berry, every leaf. You don’t want a sad bruised leaf on the plate, or some squashed tofu. You taste your cooking constantly — you clean up, you care, you love the food, you attend to it — and all this comes out in the dish and the experience. I want to be that kind of developer— I want to know that at every step I am putting love, attention and care into my ingredients. I want to be tasting and testing my recipe — is it still balanced and good now I’ve added a new ingredient? Is it the best it can be at every step?

In this context I can see TDD as my friend to being the best, and weirdly the most efficient I can be.

The myth of the lone genius…

Today has been a lesson in the application of process in the face of adversity. I started the day absolutely floored by a problem — I was confused and quickly found it difficult to focus. I was able to gain a bit of perspective and apply a couple of things I had been told the day before. Firstly I messaged my peer group to let them know what I was working on, and second I tried to put into practice the practical problem solving steps. The steps definitely helped me to move out of total freeze, but it was when another member of my group came over in person and offered to pair that things really changed. Just being with someone else facing the same problem changed how I felt, and therefore how I thought — how ready and able I was to bring my best. We shared our insights and were both frankly blown away at the progress we made. I think we had solved it in the time that I had previously spent staring. And the shared sense of achievement was so real — we took a walk in the sunshine to celebrate with another of the cohort and even managed to find some incredible pair cooked falafel.

Genius is nothing but a tired patriarchal myth.

Coming back we both then helped another member of our peer group with the same problem, trying to stay with the “coaching” rather than “teaching” style. While this helped the person we were working with, I was really struck by how much I benefited from this, the deepening of my understanding of what was really going on. We’re building on these blocks, it pays to invest in them.

This has got me thinking that this course is really about experiencing how to learn. I think I have been assuming there’s some giant library worth of knowledge that I need to consume and retain and then I can call myself a developer. I mean the truth is, even if this were true, we could never learn it in 3 months anyway. And it would be out of date. And chances are the thing we actually need to be wouldn’t be covered. So I need to relax a bit about the lists and contents and indexes. Knowledge will come — it is coming. Much more important is practicing how to find the path and do it with others.

The afternoon was more pairing — and I had the best time. I felt seen and valued. I felt affirmed in my strengths and my weaknesses. I felt challenged. And we really learnt and we really achieved. I was struck by how, at the end my brain hurt in a way that was familiar after an intense code, but that I also felt different — physically lighter — my shoulders not clenched, my eyes not popping.

School produces learners when it should be training thinkers.

I had fallen for the urban myth of the lone genius. Of the sole working coder solving problems no one else can. I really love to code, but I don’t like working alone, so that’s a really good outcome for me. And anyway, who needs that kind of pressure on their shoulders anyway?

Today has been a good day because of the people I have worked with and the practice in working together. This is day 2 — what a thing to learn to take forward into the coming days and weeks.

First day at School

Deciding to change my career, that’s a really big deal, and in many ways the hardest part has already been done. Decision made, course chosen, fees paid, pre-course completed (just…).

And so here it is, Tuesday 19th April 2022 — day one at Makers. We start on a Tuesday as it’s Easter weekend, and yesterday I was wracked with nerves which meant headache and nausea and a heavy preoccupation. I had the first day nerves and I had them bad.

What am I going to wear?

What will people think of me?

Am I going to be OK?

Obviously I planned my timings carefully — didn’t want to leave that to chance, and I arrived at 9:10 (not too early, not too late). The building is classic East London brick warehouse, and really very welcoming — Ash at reception is super friendly. I find some of my cohort and say an awkward “hello” — then a few of us go to make tea. to be honest I don’t really want tea, I want something to do.

We make our way to the second floor to begin our makers course — Eóin is our coach this week. We begin with housekeeping and hellos, the the course is outlined and we enter what is really the main theme for the day — what this bootcamp actually is, what it isn’t, how we will be learning and why that is. This is a 12 week course in learning how to learn. There is no tick-list. There is no better or worse — this is the experience of being faced with problems, and being scaffolded while we learn how to access and use the tools we need to solve them.

I leave the day feeling hugely affirmed. Affirmed by my cohort — what an excellent, warm, empathic and friendly group of human beings but also affirmed by the choice I made to be here. To be at Makers. This is not 12 weeks of “learn this and then you can”. This is a change of mindset and an immediate immersion into being a developer starting today.

Am I better developer than I was yesterday?

Yes — I have sat and pair coded in person. I have faced a problem that stumped us and our coach for long enough that I felt encouraged. And was then solved by my pair. I have been told that the most important thing is my well-being, our well-being, our togetherness — not just this cohort on this journey, but also onward into the future of my career. Today feels like the beginning of the next bit, more than the beginning of now.