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
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.
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.
The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.
“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”
“The new computer system will fix that”
“Users complain that there’s too many steps to sign off expenses”
“Each step will be faster in the new computer system”
“Staff have low job satisfaction”
“New computer system!”
“Our users aren’t interested in that new feature”
“New computer system!”
“We’ve been hacked with a social engineering attack”
“NEW COMPUTER SYSTEM!”
Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.
Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.
If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.
With a broken phone and Inbox by Google I went from 5000 unread messages to Inbox Zero in a week with some email bankruptcy and clearing out some tasks.
It’s not about being anal and keeping things neat, it’s about recognising that you’re never going to reply to that email from 2 years ago, but it’s hiding that email you should respond to.
Be ruthless. Archive, delete in bulk. That sale 3 years ago is over, you’re never going to fix that NHibernate bug, and someone else is looking at it, it’s too late to sign the petition to bless the rain down in Africa.
And as I found when my phone broke, and I got thrown back to a version of Gmail without bundles, stop hiding things behind labels. If you’re not going to read it, unsubscribe or filter it into the bin. Lose the haystack, keep the needles.
First, a clarification, the change in the DVLA is for the paper counterpart to the photo id licence, not the paper licence that existed before the photo id licences. Many people will have been switched to photo id by moving house though, so it’s only the hardcore who won’t be included.
I got confirmation from the car hire firm 24 hours in advance that I needed to print out my endorsements sheet, by which point I no longer had access to a working printer, so I was glad I’d tried it beforehand. The guy at the desk noted that it was a new scheme, and also mentioned that if I hadn’t printed it out, they would need to call a DVLA verification phone number which is very busy when it’s not shut. So still a number of teething problems to sort out.
Do if you are hiring a car, get yourself over to dvla in advance (any time within 21 days) and get your endorsement sheet printed. It might just save you from long queues and grumpy car hire staff.
During my summer break in university, back in 1999, my local council, who part funded my university education, back in the days before student loans, found me a placement at a local charity to develop a CPD database to track the exams their members took every year.
It was an Access database, installed on one machine on the network. With manual backups. It stored the pass/fail data in a set of bit fields in the database, requiring some complex sql to answer the common “who hasn’t done this course yet” mail merge query, it used VBA to parse those SQL queries into a screen full of check boxes to allow users to search.
None of that was my getting better moment though. I went from being a very shy geek at the start of the placement to a slightly less shy geek with a lot of confidence in my code. It was the first thing I’d written that was out in the real world and I was proud of it.
Until the first work day of 2000, when it stopped working. Despite the initial suspicions of the customer, it wasn’t a y2k bug. There was a bug in the end of year routine. What it was meant to do was create an empty exam results table for the new year, then rewrite the rest of the system to point to that table do that all the queries, screens and reports were up to date. It failed because it wasn’t properly tested. And I spent a whole day in their office, feeling sheepish, rebuilding the queries, screens and reports by hand to fix the mess.
But that wasn’t my big learning moment. That came exactly a year later, with another call, and another broken database. A lot of pressure now, trying to remember a fix from 12 months before on 18 month old code. It took longer than the first time, but I spent some time afterwards documenting the fix, testing the end of year rollover, and simplifying the code so I was capable of debugging it.
Luckily the customer was reasonably happy, as they didn’t run many exams in the first week of the year, and they understood you don’t get perfect solutions when you pay student placement wages, but I have tried hard since then to keep the customer happy and keep bugs that are fixed, fixed. All software has bugs in it, it’s how you deal with them, and the customer, that separates a professional from a beginner. The experience set me on the path towards TDD, open and honest communication, and not wanting to pick up support calls out of hours, which is a great motivator of quality. If you can lie on a beach, knowing you won’t get called because your code just broke, you’re doing it right.
I don’t trust change. I know change is what we do, it’s why people need new software to do things they couldn’t do before, to sweep away the cobwebs and start everything anew. To change. For the better.
The better what? Faster, more efficient, more user friendly. “Just better”. “An improvement”. “The new shiny”. “Make it cool”.
Great, can you write me a requirement for that, or some acceptance criteria?
“We’ll know it when we see it.”
But how will we know?
“It doesn’t matter. We’ll know.”
And when you come back and say it doesn’t have enough “zing” or “pizazz” or isn’t “cool” or “new” enough?
“Well then, it shows you didn’t listen to us.”
A change for the better?
If you want to change, you should know why. What will the users notice? What pain will it take away? What will it allow you to do that you couldn’t do before?
Those are questions I can pick away at, questions with an answer where I can measure something tangible. I can change the time it takes to do something, I can change a system to do something new, and I can show you exactly what the change looks like.
A change without a diff is a break.
If you don’t know why you’re making a change, the chances are, you’re making the wrong change, and you won’t know when the change is done. Make a small improvement, or a big one, but know why. If you can’t articulate the difference between the present reality and the desired future, all I can tell you is that the change will break. It might be beneficial, it might not, but there will be no way to trace from now to the future, and no way to know if anything has improved.
The best change may be no change
We love writing software, coming up with new ideas, new approaches. We want the new shiny. But that doesn’t mean it will do us, or our customers, any good. Angular.js makes it much easier to write web apps a certain way, but is that the type of web app that most suits your customer, and do they really need a web app at all? Is a web page easier for them?
And maybe what needs to change isn’t the software. Maybe there is a process that people have forgotten that will fix the problems, maybe they’re solving the wrong problem.
Software isn’t always the answer, and neither is change.
When to embrace change.
Change when things cause you pain. Subversion makes branching and merging painful. If that’s a problem for you, try git or mercurial. Manipulating the DOM from a callback is painful. If that’s a problem for you, try Angular or another framework. If they’re not causing you pain, chances are something else is, go change that first.
Change when there’s a functionality gap. When you’re chasing a new regulations, new APIs, new competitors, or new customers. And make sure that functionality does something to help close that gap. You might have a few ideas, so pretotype and prototype them first, make the change as small as possible, and build on it, because a small change is easier to throw away, physically and psychologically.
Embrace change.
But don’t trust it, until you know where you want the change to take you, and you have a way to check you’re on the right path.
I’ve been thinking about productivity a lot recently, s you may have seen if you’ve been following me on Twitter.
It strikes me though that the most important thing that generalises a lot of the tips is this: Avoid multitasking.
Humans are notoriously bad at multitasking (and not just men, for those women sniggering smugly at the back), so a lot of the tips are about focussing on one thing and ignoring everything else. Things like working through a to do list, setting aside a specific time to deal with emails and setting one main goal, are all about the same thing.
One of the reasons multi-tasking is unproductive is there is a time cost associated with switching tasks. Think about your email. To check it, you open up (or switch to) your email window, you may need to log in, you then have to orient yourself to the last e-mail (which is easier if you have an empty inbox when you end your email tasks), and then get into the mind set of what you do with each email, remember what folders/tags you’re using, and so on. The more you do a task, the shorter the switching time can get, but it is always there, and if you’re multitasking, you’re actually wasting a lot of time during the switching.
Of course, sometimes switching is inevitable, networks go down, sometimes you have to wait for other people, so you need other tasks in the pipeline so you have something to do when you can’t work on your main task, but the longer you can concentrate on one task, the more you’ll get done on that task. And if you set yourself a deadline to complete it, that’ll help your concentration too because it will stop you thinking “Oh, I’ve got a week to finish this, I can check my email now” and start you thinking “I’ve got to get this done by 3 or my plan’s down the drain, so I’ll get this done now and then check my email”.
In an attempt to steer my referrer logs away from the HTC Hero, I wanted to get back to something I mentioned on Twitter a while back. I want to talk about rabbit holes in your code.
After a while, all code will have at least one rabbit hole in it. You know you’ve found one when a simple looking change starts you scratching a little deeper because the fix isn’t working or there’s a code smell you can’t quite figure out. You peek, you dig, and suddenly you realise that a 5 minute job has taken half a day.
It’s time to step back and evaluate. Take the red pill or the blue pill. Do you paper over the cracks as best as you can or do you find out how deep the rabbit hole goes? Take the first option and you’re taking the technical debt deeper in to the red, but take the second and you run the risk of not fixing bug zero : shipping.
There’s no magic answer to the question. I can’t tell you which pill to take, but please watch out for rabbit holes in your code. Be prepared to deal with them. And be prepared to live with them. Every architecture has pain points that lead to rabbit holes, but some have more than others.
Craig Nicol 