Categories
code development programming

Software Development as a Christmas Story

Gingerbread Christmas Tree
Oh Tanenbaum

We decorated the house for Christmas. A smaller project than most of the software I’ve worked on, but a useful reflection.

The Cost of context switching

Sometimes, in the middle of one task, you need to do another. Either because you were interrupted, or because you weren’t prepared. Consider the tree, a tall tree, one you need a ladder to decorate. But you left the 🌟 in the attic.

You don’t just have the cost of picking up the star, you need to get down the ladder, fold it up, carry it upstairs, open the attic, unfold the ladder, climb to the attic, find the star, then pick it up and unwind all the other steps just to get back where you stated before you can continue the task of putting the Star on the tree.

It’s just a minute to get the star…

Yak shaving

Sometimes it’s more than just one thing. Sometimes to get to where you need to go, there’s a cascade of other tasks.

You want to put the tree up, but it’s the first time you’ve had a real tree, so you need a new base. It’s bigger than last year’s tree, so your lights don’t fit. So you need to go to the shops. But you need to fill up your car. And the tyre pressure warning light comes on so you need to top them up. And you need to check the tread depth whilst you’re there, and so on.

Programming in a nutshell

Performance at scale

Our tree stood up fine when it was delivered. But as it scaled out and the branches widened, it pushed against the wall, making it unstable in the condensed space. It fell over.

Luckily no lights or baubles were using it at the time, but it’s an interesting challenge holding up a heavy tree in one hand, trying to adjust it’s position with the other hand, as I avoided the puddles of water in the floor as my wife mopped them up. If you’ve ever worked support, this may sound familiar.

Turns out that it was harder to stabilise than I anticipated.

The branches were unevenly partitioned, providing more load on one side, so I had to stabilise it against the wall. And the tree was almost a foot taller than expected, which turned it out to be 2 foot taller than the base was rated for.

We upgraded the base to handle the load. It’s bigger than we need.

Technical debt

I have some old pre-LED tree lights and they slowly fail so each year I replace the unlit ones from the packet of spares but I haven’t been replacing the spares. Eventually, they will run out, and the spares will no longer be available. I’ll have to throw them all out and start again.

The new led ones don’t let me replace them individually. But they last longer and are cheaper to run.

Which debt is easier to live with?

With a big tree, those old lights aren’t long enough. So, do I buy another set for the rest of the tree that doesn’t match them, or throw out the existing ones and buy a longer set? The latter looks better, but throws out the sunk cost along with the lights.

You know computers, can you look at this for me?

No, I can’t fix your tree. I can navigate a garden centre. I know enough physics to keep a tree upright, eventually, and safely put the angel on, but I’ve no Idea how to grow one, or what that weird stand with 17 gears you bought does, or how to assemble your plastic one. And I’ve no idea what that bug in the tree is.

Merry Christmas. Catch you all in the New Year.

Categories
code development programming

How I approach coding challenges

This time last year I was doing a lots of tests for job interviews, and I was practicing with https://adventofcode.com

I know there’s various data structures and algorithms you can learn to make these easier (and I hope to come back to some of my favourites in a later post), but there’s a general approach I take to these that helps me, and might help some of you too.

Use TDD

I’ve always been a fan of Test-Driven Development, and these type of puzzles lend themselves well to TDD thinking. Often examples are provided that will form the initial test suite. The algorithm is often broken into steps (sometimes explicitly “On every clock tick…”)

Get into the habit of checking as you go to make the most of the information provided to you. Think about the problem first, and the mapping between the input and the output, before you write any code.

Check everything on simple solutions.

Have templates

Most challenges involve a few common tasks. Read input from a file (ignoring blank lines), create a list of…, output as CSV, etc.

Some of these will have standardised patterns in your chosen language, and you should use them. Some will likely require some error handling. Some will require loading from standard or 3rd party libraries. And all will require a test framework.

As you go, build up a utilities list of functions, classes and packages that you know how to use, are robust enough and have minimal clutter. They’re not meant to be usable by anyone but you, but you will use them a lot. Collect and cherish them.

Think simple

Technical tests and coding challenges, in general, are designed to have short, easy solutions. If you need to solve P == NP to make your code fast, it’s likely you’re using an algorithm that’s a poor fit. Find 2 other ways to solve the problem, and pick the simpler one.

Simpler than that

Think about the simplest solution that could possibly work and write it simply.
Make the code readable. This is not the time for clever solutions. When it fails on an input, make it easy to change.

But not that simple

You still need to think about edge cases, and memory usage, and a myriad of other resource constraints. Think about what could go wrong, within the confines of the puzzle. Advent of Code has a particular knack for detecting edge cases in your code for Part 2 of each day’s challenge.

Think fast

Beware of premature optimisation, but expect long inputs and many loops if you use the naive implementation. Learn new algorithms and data structures.

Categories
development programming

Somebody else’s problem

Sometimes dividing tasks creates inefficiency. When one person both cooks and cleans, they tend to create less washing up than if the tasks are divided, because washing becomes “somebody else’s problem”. However, when one person washes and the other dries, the load is equivalent. This setup can be prone to stoppages when the drainer is empty and the washer is trying to get that stubborn burnt bit off the pan, at which point any good ToC practitioner will ask the drier-upper to help with the washing to maintain throughput.

When teams are divided by layer instead of features, the interface between them becomes a fracture because each team has context missing from the other. Data has the wrong shape, validation requires fields that can’t be captured. If you build both sides, the transition is smooth.

When developers test, they can focus on smaller, independent chunks, which means fewer tests with greater coverage. Writing integration tests for complex calculations is painful and slow. Testing those same calculations as an xUnit Theory is cleaner and faster.

Specialists are great, but where is specialisation causing fractures and more work?

Categories
code development programming security

This is raw

This is raw chicken : 🐤

If you eat it like that, you may get hurt immediately, by its beak, or its claws. It may grab your money and run off with it.

If you want to eat it, better to kill it first. 💀

If you eat it like that, you may get hurt or die, in a few hours, or days. Washing it won’t help.

Cook it. Cook it well. If there’s any sign of pink, cook it some more. 🔥

It might still kill you, but at least you’re a lot safer than when you started.


This is raw data : 🐤

If you display it, users will get hurt immediately, whether by cross-site scripting, cookie sniffing, crypt-currency mining, or something else. If you’re lucky, it will be something your user’s see immediately and leave your site never to return. Otherwise they may get infected.

If you want to use it, better to validate it first. 💀

If you save it like that, your users are still vulnerable. It might appear on the front end in a different form. It might be a string of unicode characters that crashes your phone. It might be a link to somewhere they can’t trust.

Encapsulate it. Sandbox it. Never trust it, in or out . HTML encode, whitelist the output as well as the input.

And if you need to avoid spam, or incitement, or solicitation, maybe you need editors. Computers can’t fix all the social problems. 🔥

Categories
code development leadership

Tribe of Mentors – 11 questions

I’ve been listening to the Tribe of Mentors podcast by Timothy Ferris and in the related book, he talks about the 11 questions he sent out to get people to respond. He’s got a great discussion about how he refined the questions, and why he chose those questions in that order, and I’d recommend checking out the book and the podcast. I thought it would be interesting for me to answer them. If I’m going to write a blog, I should give you some insight into who I am.

The questions he asks all his interviewees are:

What is the book (or books) you’ve given most as a gift, and why? Or what are one to three books that have greatly influenced your life?

What purchase of $100 or less has most positively impacted your life in the last six months (or in recent memory)?

To give me a significantly more productive commute:

  • I have a small notebook that I can carry in my pocket, from my local supermarket;
  • A cheap bluetooth earphone for listening to podcasts, which is good for voice, but not great for music;
  • Pocket casts for managing my podcasts. I also set it up to auto-play whenever I turn by earphone on.

How has a failure, or apparent failure, set you up for later success? Do you have a “favorite failure” of yours?

Deleting a database

If you could have a gigantic billboard anywhere with anything on it — metaphorically speaking, getting a message out to millions or billions — what would it say and why? It could be a few words or a paragraph. (If helpful, it can be someone else’s quote: Are there any quotes you think of often or live your life by?)

“Do not compare yourself to others for you may become vain or bitter. There will always be greater and lesser persons than yourself.”

Desiderata, Max Ehrmann

What is one of the best or most worthwhile investments you’ve ever made? (Could be an investment of money, time, energy, etc.)

My PhD. I learned discipline, I took the opportunity to learn lots of new technologies, and to sit in on some random lectures.

What is an unusual habit or an absurd thing that you love?

I love weird films and music, such as Trout Mask Replica, Eraserhead. Things that I don’t choose all the time, but reset my expectations about what art can be. It’s always good to get a refresh to help my problem-solving and avoid getting stuck in a rut.

In the last five years, what new belief, behavior, or habit has most improved your life?

Regular blogging. It has helped me to crystallise my thoughts; share ideas with others, and my future self; and led to some great conversations.

What advice would you give to a smart, driven college student about to enter the “real world”? What advice should they ignore?

It’s OK if it takes you a few years to find the right job for you. It’s ok to have a few jobs on your CV if you have a reason to move. Treat them as a chance to find out who you are, and don’t let golden handcuffs make that decision. Bank the cheque in case you need a parachute.

Don’t work on your free time to get a job. Do what you enjoy. Climb hills. Practice the guitar. Volunteer at the hospice. Spend time with friends and family. Jobs that require you to learn on your own time are jobs that don’t respect you.

What are bad recommendations you hear in your profession or area of expertise?

April Wensel covers this better than me. I felt an unease about things, but April Wensel managed to capture it much better than I could. Don’t be a hero. Be a team player. Don’t follow these toxic tips.

In the last five years, what have you become better at saying no to (distractions, invitations, etc.)? What new realizations and/or approaches helped? Any other tips?

I became a dad during this period, and time has become far more precious as a result. Family comes first. So less TV in the evenings, more time with my daughter, more together time with my wife. Less news, less shouting at the TV. If it’s not something that I’m passionate about, or will help my family, me or my friends, I can’t justify the time.

When you feel overwhelmed or unfocused, or have lost your focus temporarily, what do you do? (If helpful: What questions do you ask yourself?)

Go back to my task list. What’s the best thing to do now that my future self will thank me for?

Categories
development ux

Work hard to make things simple

Bowling Alley

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” ERNST F. SCHUMACHER

It’s easy to write software. Ask users what they want (or even better, observe them and discover their problems), find a clean, user-friendly solution, build it and deliver it, for free, with no ads.

And you make a success of it, so you add more features to see off the competition, or to disrupt a new market. Google built Gmail, then added automatic categories, and Smart Replies to make it easier to process your messages. And they also added Wave, Buzz, Google+, Talk and others, to demonstrate other ways to connect and communicate, for places where email doesn’t work so well. So many new features, new things to learn, spinning out from that new core.

And yet Gmail remains popular, the rest, not so much.

It’s easy to add features. With a bit of work, you can even add them seamlessly without adding another menu option that your users will never see.

But what’s your plan to remove options, to streamline your code? How do add a new feature that’s easily discoverable and useful? How can you be smart and subtle?

What is your simplification strategy?