Categories
development programming

Things I don’t know as of 2021

Things I don’t know

Last time round, I stated the things I didn’t know. Whilst the technical list hasn’t changed much, there’s a new set of skills I want to talk about for this year, as these are the things I want to know.

How to build a diverse team

I’ve worked in plenty of diverse teams, and I’m proud that we managed to build a team from all male to 50% female in the 2 years I was at my last job, but there was a lot of unique features about that job that makes it harder to replicate elsewhere. And some of the groundwork was laid before I joined.

How to be a good mentor

I started mentoring via coding coach last year, and I’ve had to tune my approach to each individual, but I’m still not sure the best questions to ask, and what’s the best structure. If I find out, I’ll share it here.

How to get a sleep routine

Sleep is important. But between the existential crisis of a global pandemic, with the subsequent upheaval of work processes, and the constant desire to get more done, I don’t always timebox what needs to be done, and things fall, including my blog, and my fitness. I have thoughts on how to prioritise and plan better, but I can’t control for external factors.

How to work remotely

Whilst I’ve been used to sort periods of working from home and working with teams spread across multiple offices, this COVID lockdown is different.

I’ve learned how to work asynchronously, but there’s no good replacement for the serendipity of a chat grabbing a coffee or over lunch. Whilst I’m cautious about returning, even when we can, I definitely look forward to seeing people in the flesh again. Even if we’re wearing masks.

Is there a better way to work?

Whilst trying to find how to work “like this, but over video”, I’ve started looking at how properly remote-first companies do it, reading DHH and Reinventing Work, and thinking if there’s a better way of organising work completely. Asynchronous, pull-driven, self-organised. How do open-source and open-contribution (e.g. Wikipedia) work, and are there lessons we can learn there to make companies more effective, more value-driven and more scalable?

Categories
.net code data development

CosmosDb in The Real World : Azure Global Bootcamp 2019 (Glasgow)

Thank you to those who came to my talk today about CosmosDb. I hope you found it useful.

If you’d like to review the slides, you’ll find the presentation online here :

CosmosDb In The Real World – GitPitch

If you have any further questions please ask below and I’ll do my best to answer.

Categories
code data development

Zettel Lint


title: vision
created: 2020-10-11 21:48

There are many editors and extensions for working with connected markdown files. As I am working on multiple devices, it’s hard to find a single editor that works on all of them, and different editors are optimised for different things. In the spirit of UNIX, therefore, I wanted to write a suite of small programs (here coded as sub-commands) that will allow the connection and management of markdown files via automated processes, such as github actions, so that the knowledge base can be updated from anywhere.

This tool was originally created to manage a zettelkasten based markdown powered git repository.

Principles

  • All outputs should use standard formats, mostly markdown, but some usages may need something more specific.
  • All subcommands should be independent so that users can pick and choose whatever suits them.
  • Modifications aligned to particular practices (e.g. GTD, Zettelkasten, bujo) should live in their own subcommands.
  • This tool should not impose structure on the knowledge base.
  • Repeated application of a subcommand should only modify the knowledge base at most once, unless external factors apply
  • External factors include time triggers, update of import files

View on Github

Categories
development leadership

Ask Your Mentor These 40 Questions : failure (Q1-10)

Lifehacker suggests 40 questions to ask your mentor. So that I don’t have to repeat myself, I’m posting the answers here in 4 chunks.

1. What’s a big mistake you’ve made that you’d want others to avoid repeating?

Never take responsibility away from a team. Empower them and trust them. If you lead a team, don’t tell them that the buck stops with you, tell them that the buck stops with all of them. You can defend the team from others, and take responsibility for failures externally, but always make sure everyone is accountable for their own work and you all succeed together or not at all.

2. What’s your strategy for overcoming failure?

Move on. Leave the failure in your notebook, or in your action log. Own the failure, understand why it happened and work to avoid that situation in future. Put safeguards in place, rework the environment, but don’t expect future you not to fall into the same trap as current you. Move the trap where you will notice it.

3. What’s an essential lesson you learned as a result of failure?

An untested backup is a wish, not a promise. Test it to make sure its a promise.

4. When should I give up on a pursuit?

When it no longer provides value. Or there is a better way to provide the intended value.

5. Do you believe in the sunk-cost fallacy?

Absolutely. And I have worked on projects that recognised this, restarted from scratch, and delivered for less than the change in estimate to continue the project.

6. How do you assess what feedback is legitimate?

It’s specific, The person giving it has your trust, or the trust of others you respect, It’s given in kindness even if it’s given with force.

7. How do you integrate feedback into your work and lifestyle?

Always listen. Ask for feedback. But most importantly, act on the feedback, and show yourself acting on feedback, because that always encourages more. If feedback is lost, new feedback is never given, because what’s the point?

8. How big of a risk is too big of a risk?

Depends on the project. A team of 1 can handle a much bigger risk than a team of 100. A team with a strong PM who manages risk well, can handle more risk than one with a weak PM.

9. How do you determine which weaknesses can be overcome?

Ask. Whichever weakness you have, someone out there is thriving with it.

10. Can you tell a story of how you recovered from a massive blunder?

[I deleted a database]

Categories
development lifehacks quickfix

What are you doing now that your future self will thank you for?

There’s a lot of productivity guides and self-help advice out there, but if you really want to make a lasting change, you need a mantra or a question that cuts through all of that and helps you focus. I know some people like Does This Being Me Joy? Is This True To My Inner Self, or What Would Joe Do?

I think whatever it is, it has to be yours. Mine is “What are you doing nw that your future self will thank you for?”, and was forged out of “write your code as if the next person to read it is an axe wielding maniac who knows where you live” with the footnote “everyone can become an axe wielding maniac at 3am in the morning when nothing is working”.

Be kind to yourself. In the moment, of course. But to really find peace and satisfaction, you need to be kind to your future self.

  • Write a test suite for your future self so they just need to add one more test for that error condition you didn’t think of, instead of having to write the entire harness.
  • Be smart enough to write dumb code. 3am you is not as smart as now you, and has forgotten the context you currently have.
  • Do the dishes. Especially the porridge bowls.
  • Embrace Mise En Place. Prepare your space, lay things out beforehand. Even the night before. Tomorrow you will be happy not to search for things before morning coffee.
  • Get some rest. Tired you doesn’t like Doomscrolling you.
  • Switch off from work. Future you didn’t want to be an always-on stress bunny. Future you would much rather know tourist French or the 4 Seasons on guitar.
  • Document your decisions. Especially design decisions. You can never have too much context.
  • Always be ready for your next holiday. Write things up as you go. Don’t be irreplaceable.
  • Share 80% of something ok and get feedback to turn it in to great, instead of trying to release 100% fantastic. Future you likes the conversations the feedback sparks, and that last 20% wasn’t the way you would have done it alone.
  • One small step now is far more effective than a possible leap in the future.
  • Valuable unfinished tasks pay compound interest. Figure out how to find the valuable ones.
  • Check in with your past self once in a while and think about what you would do differently to make today easier. Then do that.
Categories
development programming security

Litterboxing

Sandboxing is a great idea. Isolate your processes. Isolate your data. Chinese Walls everywhere to ensure everything is kept separate, independent and secure. Whether that’s containers or SELinux

Litterbox – it’s like a sandbox but when you look closer it’s full of shit

“There’s the inkling of a good idea in there. He’s almost describing a sandbox (without, of course, any of the isolation required) and front-end microservices (without a pipeline, or components). Can we call this pattern litterboxing? It’s a sandbox until you look closer and see it’s full of catnip.”

https://thedailywtf.com/articles/comments/classic-wtf-i-am-right-and-the-entire-industry-is-wrong/1#comment-506416

Categories
cloud development programming

Cloud thinking : Executable documentation.

Documentation is just comments in a separate file. At least developers can see the comments when they change code. Tests are better comments. Tests know when they don’t match the code.

Infrastructure is the same. I can write a checklist to set up an environment, and write an architecture diagram to define it, but as soon as I change something in production, it’s out of date, unless it’s very high level, and therefore only useful to provide an outline, not detail.

Unit tests document code, acceptance tests document requirements, code analysis documents style and readability, and desired-state-configuration documents infrastructure. All of them can be checked automatically every time you commit.

Documentation as code means the documentation is executable. It doesn’t always mean it’s human readable; ARM templates in particular can be impenetrable at times. If machines understand it, the documentation can be tested continuously, repeated endlessly across multiple environments, reconfigured and redeployed at the stroke of a keyboard.

The more human you have in a process, the more opportunities for human error. It doesn’t remove mistakes, but it’s much easier to stop the same mistake happening twice.

Categories
development programming

Modular doesn’t mean interchangeable

Microservices are great. Containers are great. Packages are great. Objects are great. Functions are great. At each level they encapsulate functionality into re-usable modules. One place to make changes. One place to optimise. One abstraction to help you move to the best layer.

For the sake of argument though, I’m going to focus on microservices, specifically those accessed via an API, as that’s what I know best.

Interfaces and APIs are good for test harnesses, but isolating systems for your own benefit (to make modules open for extension but closed for change) bears no relation to making that module useful to other systems.

Sure, I could rip out the modules that contain business logic, and package it as a framework, but that doesn’t mean it’s useful for anyone else. It could well be an inner system . It may still be coupled to domain/architectural knowledge that make it too valuable to swap out. There could be an implicit dependency for just that one version of that one tool.

It is of course possible to make modules re-usable, but they have to be designed that way, whether up front, or evolved. And anything interchangeable has to be tested, in at least 2 conditions, to make sure it’s suitably robust.

Design an interface. Evolve the design. But don’t mistake solving one problem in one place for a general solution. And don’t think that adding an interface is all it takes to turn a local SQLite data store into a cloud file system repository.

Categories
development

Blank slate

I’m a fan of the original Sherlock Holmes books, and there are a few things in them that talk about an enlightenment way of thinking that’s useful for a developer when gathering requirements (whether tomes, user stories, backlog ideas,etc), writing code or approaching debugging.

Today I want to talk a bit about A Study in Scarlet, and the early conversations between Holmes and Watson before their first case together, because they capture the essence of his enlightenment thinking very well.

Ignore Irrelevant detail

Watson tells Holmes that the sun rotates around the earth, as he is surprised that an educated man does not know this. In reply, Holmes says,
“That’s very interesting, I will now do my best to forget it”

It’s not an important factor in any of his cases, it doesn’t affect his work, so it’s not a fact he needs to record. He accepts it but has no way to act on that information, so he dismisses it.

It’s something that is often hard to do in requirements gathering and may need to be done retrospectively after you find out whether Andy from finance’s love for Richard Branson is just infatuation, or it means that every call to action across your site will need to be red.

It’s also something to apply more generally, choose what to ignore, don’t learn every new JS framework. Don’t expect to be an expert in everything. Be content with being T-shaped, and become an expert in solving problems and focusing on the right details.

The Book of Life

” it attempted to show how much an observant man might learn by an accurate and systematic examination of all that came in his way.”

The truth is never simple. Whatever you build will be part of an ecosystem comprised of other software, of manual processes, of fallible humans, and the winds of fate.

Gather whatever information you can, in whatever detail you can. Organise it and understand the bigger context.

The Phoenix Project has a great understanding of this in the discussion of the SOX-404 audit, where the IT department are busy worrying about controls on software without understanding the manual processes surrounding the software and how that fits into the compliance picture.

Speculation

On their journey to their first case together, Watson is keen to speculate about the motives and means that led to the crime, extrapolating from what little information they got from the initial introduction.

Holmes quickly and sternly cut Watson off from that line of thinking. He was clear that he would also base hypotheses on the causes and consequences once he had evidence before him to narrow down the possibilities, removing the impossible.

Speculate make hypotheses on why the system failed, on what will improve sales, on what the performance bottleneck is really going to be. Without data or a way to test them, they are useless for reaching understanding. Sometimes the beauty of a forest can only be appreciated by the birds.

Remove your preconceptions and bias from judgement by understanding what they are. Follow the data instead of your gut.

Categories
development

When the old guard are not heroes

When I started programming, there were some key figures identified as the experts. They wrote the books that laid out how my code should look, how I should behave, and what the purpose of a software developer was. And there’s a new guard, also steeped in that mythos, publishing their hot takes and simple books.

I looked to my peers and seniors for guidance, and they looked to the agile manifesto, the gang of four and others. Those who packaged up existing ideas and best practices, set against a growing trend of Taylorism, and wrapped themselves in a punk ethos fighting the power, wielding keyboards like axes.

And there was value in what they were selling, small pieces that fed my hunger for “something better”.

But for all the bravado, the facade of Woody Guthrie and Bruce Springsteen they presented, deep down they were the establishment, tweaking the system slightly for their own benefit, re-engaging the bro culture of the “frontier spirit” of the early internet. Rules and processes are dictated by “the man” to restrict our freedom to innovate, and to work in the best way.

Companies formed and rose on the counter-culture ethic, buoyed by the vacuum left as union power fell, blinding us all that tech was the new utopia, and it brought a meritocracy that would bring equality.

And the gods saw agile, and it was good.

We moved fast and broke stuff, re-wrote the rules. The industry didn’t take time to consider why those rules existed, just that they were roadblocks.

So when women and people of colour, and anyone else who wasn’t a bro, stepped into the arena, they were vulnerable. Because there were still rules, just no process. And the rules aren’t made for them. And the gatekeepers, clear in their self-image that they weren’t racist, or sexist, and only discriminated on merit, could not comprehend that processes and written rules exist to limit privilege, because equality means nothing without equity.

They asked all of us, the squirrels, the rhinos, the fish, and the peacocks, to climb trees and collect nuts to demonstrate our worthiness to join their club, without regard for our skills or our backgrounds. They bully, they fight, they protect their own, because rules weigh us down, man.


  • People over process, so long as the people are the right people.
  • Working software, so long as it works for me. Anything else is externalities and not my problem.
  • Collaboration over contracts, we’re all on the same team, so forgive me as I forgive you.
  • Respond to change over following a plan, but is there a vision that informs what changes are acceptable?

Agile still has its place, but what would it look like if the manifesto and the guiding principles had been laid out by a more representative group? The antecedents, stretching right back through NASA, Bletchly Park and The Difference Engine, remain the same, and the key lessons are independent of those teachers, but what did we miss by not having others at the table?

  • What does process that protects people look like? Process that keeps people safe and secure to deliver the best solution?
  • What does software that works for everyone look like? Beyond documentation on accessibility and anti-discrimination.
  • What does proper, honest, compassionate collaboration look like? Within teams, between teams and across disciplines?
  • What does meaningful, people-centered change look like?

Software is too important to be left to the swamp that is this libertarian mess. The current ways are driving great developers out of tech, and users are not fairly represented. Some of the old guard recognise this, but many don’t, and they have plenty of followers who still believe the meritocracy myth.

There is no level playing field in tech.

Not everyone has spare time for technical exams outside work hours. Not everyone is comfortable pair programming. Not everyone can follow a spoken stand-up. Not everyone feels safe to bring their full self to work. Everyone is not treated the same. Not everyone can have alcohol and pizza. Not everyone has the experience of standing up to authority figures. Not everyone can be themselves without being judged or mocked by the cis straight white male gatekeepers, and their supporters.

There’s precious few unions and the biggest tech companies are all struggling with human rights, fair employment and treating their users fairly. And it’s not just them.

Unlike the 20th century, it’s not a battle between management and worker. Agile has cast management and worker in the same side, but some workers are far more equal than others.

People are not supported by the process. Software doesn’t work for everyone. Collaboration is limited because contracts don’t protect and promote safety. The plan for meritocracy to end discrimination isn’t working. How are you going to change it?

Categories
development leadership

Get uncomfortable

This blog is about technical topics and being a technical lead. Understanding architecture is part of it, but if you don’t reflect on understanding people then you will never be a leader. I don’t have all the answers but it starts with accepting you can learn from others, and some of what they share will not fit with your current world view. Be ready to tear down and rebuild some foundations if you’re a technical person willing to become a leader. In the spirit of learning I’ve included the original tweets at the bottom for context so you can see the rest of the conversation.

Data needs the right questions

I trust science, so data beats anecdotes, but once I started to listen to people’s stories, I realized the people collecting the data weren’t asking important questions. “How many women applied for this job?” “How many targets of violent crime are gay?” “Are black men targeted by stop and search?” Some of these questions now have better answers, but there’s still a lot of questions that don’t even occur to people to ask.

I learned a lot from my wife in that respect – the importance of qualitative research to make sure you’re asking the right questions. But qualitative is “soft science” so isn’t as well respected, despite being fundamental to getting it right. Sound familiar?

And then you have to ask why the data isn’t collected? Is it a blind spot, or do people earnestly not want to know because then they’d have to face up to uncomfortable truths that their image of themselves does not match how others see them? Our egos are fragile, which is why I have to work hard and compassionately with new developers to understand ego-less code and collective ownership. Vulnerability is hard, especially for men in tech, and that manifests itself in many defensive micro-agressions.

I’m not going to talk about toxic masculinity here, but please go watch The Mask You Live In to hear a US perspective on how “manning up” is creating a toxic environment.

Code needs the right questions

Yeah, code is for solving the problems you know about, but how do you solve the problems you don’t know about?

If someone calls you a snowflake, or an sjw, just for asking a question, there’s a very important reason they don’t want you to ask that question : they’re scared of the answer.

Let’s be clear, science and data matter, otherwise the opinion of some white guy who can’t keep his job at Google is worth as much as someone who has collected, reviewed and summarised all the data. But we all need to be sure that the right data is collected and the right questions are asked.

To be honest, I started down this path because I saw my friends were hurting, and they helped me understand homophobia, and then I started seeing where everyone else was disadvantaged. Having a friend to guide you is the best way to open your eyes.

Why should you change? Because “we’ve always done it this way” is the worst justification for anything. Because if you find out something is broken, it should make you uncomfortable. And if you think nothing is broken then you shouldn’t be writing software and fixing problems.

Make space

This isn’t about feelings, or political correctness or any of that. This is about you doing your job, understanding the domain that the technology you create sits within. It’s about bringing your full self to work, and making sure everyone else on the team has that opportunity too. And if they don’t want to talk about what they did at the weekend, that’s their choice too.

If you can’t make space to accept that other points of view are valid, that technology mediates access and knowledge, and your code will directly impact someone’s ability to access that, you should not be in this industry. Make space for someone who gives a shit about the users, and the wider community affected by every decision you make in every line of code you write and review, and every interaction associated with that code.

Is it exhausting? It can be. Especially at first. But you know what’s really exhausting? Fighting… technology…

Every

Step

Of

The

….

Way.

Don’t accept the status quo

Don’t be the developer that makes their colleagues rage quit. Or makes the users curse their every day stuck because you didn’t ask the right questions.

Did you test your facial recognition on black faces?

Can blind people order pizza on your website?

Is every woman on your team made of regular polygons and has regular periods?

Question everything. The truth is out there if you care to look. Other people should not be alien to you.