Why is CSS hard?

CSS is a real language, and you need deep technical knowledge to understand it. But plenty of software developers hate it and look down on it. It’s a good, if incomplete, tool for what it does. But I think it scares some of the gatekeepers who were drawn to software before the web.

It can’t be unit tested. It’s a language that only exists in a domain that stretches multiple sizes, multiple devices and multiple renderers. There’s more than 1 way to do things. And some of the biggest challenges with CSS are human. It’s the paintbrush for the bike shed.

https://twitter.com/craignicol/status/1074330589107507200?s=19

Funny how many hard problems in computer science, including cache invalidation, are about users.

Advertisement

If you truly want people to be creative and innovative, take them off the clock

That doesn’t mean no deadlines, but no timesheets – don’t justify every 15 minutes with a project, because the next ideas aren’t about 1 thing, they’re about connecting multiple things.

They’re about taking time to pause and thinking about the bigger picture: what problems are you seeing in multiple places? Where else would that new thing you’ve built be useful? What are multiple clients asking for?

Mise en place architecture

I love working with smart people. I learn a lot and it gives me energy.

I hate working with smart people who aren’t motivated. They’ll either get sloppy, get a new job, or get creative with their code design. The kind of creativity that makes you curse when you’re debugging a production incident at 3am.

The best creativity happens in a constrained environment, which also happens to make the easiest debugging.

Sure, we could let the developers figure out the best way to do something for every component, and there’s sometimes a benefit, but for every hour they’re spending figuring out how to solve a problem that didn’t need to be solved, or figuring out an unusual design, or evaluating a logging package, or writing boilerplate, there’s an hour not delivering value.

When an architecture is designed to put everything right where it should be, where decisions that have already been made are baked into the code and the tools, where a developer doesn’t have to think about how to structure their solution, the code is easier to write, easier to review and easier to debug.

Chefs like to follow mise en place. Everything in its right place. Before preparing a dish, prepare the workspace, the knives, and the food. Everything you need for the task and nothing you don’t. Everything is in a predictable place. Because then you can concentrate on the dish, instead of the kitchen. Good preparation helps every task fall into the pit of success, and makes it easier to recover if something goes wrong.

The more steps you have to complete a subtask, the easier it is to make mistakes. You might forget what the previous step was, you might walk to the fridge and then have to return to your workspace to remember what you need. Multitasking adds friction and adds opportunities for error.

That’s why we want encapsulated classes and single responsibility. One change updates one file, as far as possible. Although one feature may cover many changes in order to make it possible. Isolate your code from the data store, isolate the public API from your code, parse don’t validate.

Keep smart people working on solving new problems, and keep them consistent, because that’s the way to get the best from the team at all times, especially when you have a Priority 1 to update a logging framework at 3am.

You need a manifesto

My software engineers’ manifesto:

1. We write software to solve problems, not to create them.
2. We write software for everyone.
3. Those who don’t write software have things we can learn from.
4. Always leave the project better than you found it.
5. Sometimes the best contribution you can make is not writing code.
6. Sometimes the best contribution you can make is deleting code.
7. Sometimes the best contribution you can make is by talking to someone.
8. Software is inclusive. Women broke the Enigma code, and black women got us to the moon.
9. If you don’t hate in 5 years what you’ve written today, you haven’t learned enough.
10. If you don’t have compassion for whoever wrote that code 5 years ago, you haven’t learned enough.
11. If anyone can’t use your software, that’s a bug. Prioritize accordingly.
12. Overtime is a bug.
13. Debug your processes with as much attention to detail as you debug your code.
14. Asking for help is a sign of strength.
15. Work with the best. Don’t lower your standards to only work with straight cis white men.
16. Be pragmatic. Shipped code is far more useful than perfect code, but if you can have both, future you will thank you.

Inspired by: You Need A Manifesto https://pca.st/episode/33cb401f-a028-4de2-b20d-ec2c96f2b019

Thinking outside the box: the difference between constraints and perceptions

You need an app.

The constraint is that it has to be accessible.
The perception is that it has to be screen reader friendly.

But… That excludes deaf people who miss the audio cues in the app
… That misses the option to add voice control. If it’s a booking app, why not talk through the booking?

---

The constraint is that users need to be notified (it’s a legal requirement)
The perception is that only one channel is acceptable (must be post, must be a tracked email)

But… each user has their own preference, or accessibility baseline. Post only may help, or hinder, victims of abuse. I can’t guarantee that you’ve read a letter, but I can guarantee you’ve hit the “I read this” button.

---

The constraint is that you need to mark and control personal and sensitive data because of GDPR, and you need informed consent to do that

The perception is that making users click “I agree” is informed consent
The perception is that gaining consent absolves you of responsibility to mark and control personal data “because they agreed to our terms and conditions”
The perception is that location data isn’t sensitive, even though Google knows your home and work address, and the address of the abortion clinic, the LGBT nightclub, the local mosque, the local love hotel

Journaling for technologists

I encountered a question online recently about building context quickly, and whilst I thought of the bootstrapping post I made before, I also wanted to take a chance to explore how that plays into continuous practice. I started journaling as a researcher to remind me of all the dead ends and configurations I’d tried. Although I’ve not been entirely consistent in journalling (or sometimes blogging) each day and each new discovery, I think it’s a good practice for technologists to develop. Think out loud, even if it’s to yourself.

When building context on a new project, for example, I often find it useful, as part of discovery, to note what the client (or in very rare circumstances the written requirements) says it does, as well as what it actually does.

And always, always, journal everything. How to get it running locally, how to release, who knows what, who has the admin rights,… Anything that takes more than 2 minutes to figure out.

Sometimes that journal will take the form of shared content to help the next person join the project (and like all good scouts we should leave a place better than we found it), but the important bit is to write it for yourself. 80% of the time future you won’t need it, but that 20% makes the time absolutely worth it.

Don’t be a speed shaver

CW: description of blood.

There’s a deadline looming, and your estimates show the project coming in late. Very late.

You need to claw it back. Drop the ballast and become a lean mean coding machine.

---

You have a plane to catch. You look at your watch and you’re going to be late. Very late.

You need to cut corners. Shave as you shower. No time for shaving foam in the mirror.

The first cut is annoying. Your cheek stings in the heat, but you keep going.

A second cut, right on the chin. That one hurt. And it’s dripping rather than seeping.

But you need to finish. You don’t have time for this. Keep going.

Missed a bit, back under the chin.

4 cuts. 3 seeping and one dripping.

And the heat keeps them open.

So you patch it over with tissue once you’re out of the shower, try and clean it up to see what you’ve missed. And then you have to go back in and finish the job with cold skin, so more nicks, and more time is taken.

Aftershave to help seal and clean. That’s sore. That’ll sting until you get on the plane.

More tissues, and then plasters. Trying to get dressed without getting any blood stains, so that’s slower too.

---

Every shortcut you take has consequences. Technical debt pays interest, and sometimes it’s eye-watering. The debt exceeds the functionality and the project takes longer, and even longer than that. And so you have to make more cuts and ensure more pain. And still, your clients can see it’s held together with plasters that are already starting to peel.

Don’t be a speed shaver. You don’t have enough time to do it quickly.

No one thinks like you

Don’t make the mistake of thinking you’re the smartest person in the room. You might be the most knowledgeable about your specialist subject, but being a good boolean whisperer does not automatically make you an expert on public transportation, psychology, poverty, history, finance, or any other industry.

I’ve had the privilege of being disabused of that notion very early on in my career, surrounded by statisticians, linguists, psychologists, designers and vets. I do what I do, and let my curiosity take care of the rest.

But there’s a lot of arrogant arseholes in this industry who think they know best. Those who will talk instead of listening, who belittle, interrupt and condescend. They know their domain very well and are quick to criticise others who don’t understand.

But we all have our own models of how the world works, our own coordinates on the axes that describe the world as controlled by us vs controlled by others, whether money or relationships are more important, whether people matter more than animals, whether humanities can survive without science or science without humanities, visual thinkers or verbal thinkers or lingual thinker or kinetic thinkers. We don’t perceive or act in this world in a way quite like anyone else. We all bring unique experiences and perspectives to the table, and we all know something that others can learn from.

So sit and listen in silence. Take in what you can, and when you’re ready, ask questions. Listen to understand, not to respond, not merely to be polite, but because you are interested and you want to learn.

If we could see how others see us? They’re talking. All you need to do is listen.

Ideas for a second coding project

You’ve done the tutorial, what to build next?

Maybe one of the following:

• To-do app
• Shopping cart (up to the point of collecting payments)
• Bouncing balls

Don’t worry about building something unique. If you’re building something with lots of examples, you’ll have something to refer to when you get stuck.

Find something you know. Something where you can write down 5 requirements now without research because it’s something you use or an itch you have. And then you can work back from those requirements to the features you need to build. That’s the heart of programming. Not writing for the computer, but translating from human to machine, breaking things down and formalising them into simple rules.

And that’s when you realise programming usually doesn’t involve maths. It’s about thinking logically. What are the mechanics of the feature?

It’s not: I want list of tasks. It’s:

• When I open my tasks, then I can add a new one or mark an existing one as complete.
• When I type in a text box and hit Enter, then a new task is added to the list.
• When I click the checkbox next to the task, then the task is removed from the list.

There’s an action and a reaction that the machine understands. There’s choices of actions that the user can make.

Use what you learned in the tutorial to translate those actions into simple functions, and to translate the choices into a user interface, whether web, native, command line or API. Then look at it, and make it easier, faster, more secure, or add more features.

The goal here isn’t to learn a specific language, although it will help you do that, it’s to think about how to take an idea, or a requirement, and translate it into something the computer will understand. I think this is the hardest part of the journey, but it’s the most important. I’d also recommend trying programming challenges such as Advent of Code or Project Euler to get practice of writing and thinking.

Good luck on the next, biggest, step of your programming journey.

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.