Learning to Write Code that is Good Enough

When you go through school you’re always taught to do your best, to try to make the thing you’re working on the best it can possibly be. When it comes to software we naturally want the same – we dream of something that’s fast, accessible, responsive and free from any bugs. It’s just not realistic.

Need for Speed

In the real world of web or software development, speed of development is key. We have to deliver functionality by deadlines. This might be because users need it for a fixed date, or maybe you need to move quickly to make the most of a gap in the market, or you need to beat your competitors or keep pace with them – there are many reasons.

Let’s say we’re adding a new feature to search and filter product data. We’ve estimated that the full feature will take 4 weeks. However, we can deliver a very basic search box that just matches all product text within a week. We can actually deliver about three quarters of the value to the end user in one quarter of the time.

The need for speed means that we can’t take our time and build the perfect solution. We need to be fast and that inevitably means compromising and cutting corners. It’s OK to release something that isn’t perfect. It’s even OK to release something with known bugs.

Release Early

By getting the code into production and letting users try it out earlier we can use their feedback to steer the rest of the feature. Maybe after the first release we realise that this is all they need and we don’t need to build the rest? Maybe it’s too slow in the real world and we need to go back and improve this before adding more complexity? Maybe the known bugs are not quite what we thought they were?

This is general agile development, starting simple and building in iterations, and is largely about good planning and communication. We can apply the same kind of thinking to the coding.

Coding Shortcuts

Can we get away with a hard-coded list or a static JSON file for now instead of creating a new database table or API?

Can we select defaults on dropdown lists or radio button groups so we don’t have to add required validation?

Can we use browser storage rather than writing to the database?

Can a form just post key-value pairs to an email address to begin with while we’re working on the database?

We don’t need polished design or animations until we know the solution is right.

I’m sure you get the idea. Not perfect, just good enough. Go fast, hit the deadline, listen to feedback and improve it when the pressure’s off. If you’re releasing something that you feel is risky do it under a ‘BETA’ or ‘Experimental’ flag so users know what to expect and it doesn’t damage your reputation.

Reasons for Developers to Have a Blog

One thing I’d definitely recommend to any new developers is to have your own blog. It’s also a view I’ve seen shared by a lot of experienced developers. But why?

How I Started

I’ve had this WordPress blog up and running since summer 2008. I know. A long time. I had a small static website for about 5 years before that. For me it came out of necessity. I was doing freelance web design so needed somewhere to promote my services and showcase what I could do. I started writing articles as a way of creating fresh content in order to climb the search engine results listings. This certainly did not have an instant impact but over a long time I think it did make a difference.

When I started writing articles I knew that nobody would be reading them. I’m a realist and accepted that from day one. I was writing for myself. I still see it this way. It’s for me and if it helps someone else, that’s a bonus.

Knowledge Base

When I learn something interesting that I think is worth holding onto I write about it. It’s a good way of helping to commit it to memory as well as creating an easy to find reference point to come back to.

With anything of a technical nature, putting it into your own words and using your own mental models really helps you to fully understand it. It’s a bit like the idea of learning by teaching. If you’ve ever done a presentation you’ll know that the preparation you do really helps strengthen your own knowledge of the subject.

Your Journey

A bit like keeping a diary having your own blog will let you see where you were a year ago, 5 years ago, ten years ago, or more. It’s like a record of your own journey within the technology and the industry.

Show and Tell

However, in my opinion, these are not the best reasons for having a blog. I think that the best reason is having something to show for your time. By putting in some time to write, little and often, over time you build up a nice collection of your thoughts, ideas and opinions. You have evidence of what you’re into and what you spend time thinking about.

Put yourself in an interview situation, going for your dream developer job. You can show your blog and right there you have strong evidence that you are passionate about the subject and that you willingly invest time and effort in it. That has to count for a lot. It shows more commitment and serious intent than social media activity.

Writing Tips

You don’t have to be good at writing. Even the best writers improve over time. Keep going and you’ll find your way.

Don’t beat yourself up if you haven’t written for a while. Just do it as and when you want to. Don’t force it and write about something you’re not that bothered about just to get content.

Similarly, don’t feel it has to be long form and 1000 words every time. It’s fine to just share an idea in a few sentences.

Self Hosting

Another recommendation with writing a blog is to host your own site so that you retain 100% ownership of your content. There are numerous tech blogging platforms (e.g. medium, dev.to) but owning your own content and having any traffic surges benefiting you rather than the platform is definitely worth it long term.

If you do use a third party platform check out the export options. Can you get all your content out and move it elsewhere? It’s good to be free to do what you want with your work.


There are lots of blogging platforms and software options out there. Personally I’ve always found WordPress is the best fit for my needs. The fact that it has native apps means that if I’m out and about and suddenly have a great idea for a post I can capture a quick draft there and then.

It’s also very easy to export and import your data, meaning you can shift content from an old blog to a new one, combine or separate blogs, and move between hosted (.com) and self-hosted (.org) versions.

The control over the design and ability to switch themes easily means you can keep your site fresh without having to worry about rewriting the content – there’s a perfect separation between content and presentation.

The Dangers of Logic in CSS

We can do a lot of logic in CSS. I’m thinking specifically of scenarios which take the form “if this, then that”.

There are media queries which will let us control the appearance of elements based on a variety of factors. Probably the most common is screen width, so we get things like “if the width is 1024px or higher, then show an extra element”.

There are pseudo selectors like :empty, :checked, :valid, :disabled which let us control appearance based on state, giving us, for example, “if the parent element has no children (:empty), then change its opacity”.

We can also do logic based on combinations of elements or selectors, like li + li, for example, “if the list item follows another list item, then give it a top border.”

I’m sure there are plenty more ways of applying logic but you get the idea. Each of these is equivalent to writing a conditional statement in a programming language – if this, then that.

The big question is, should we be doing this in CSS, and is there a point at which it becomes too difficult to manage in CSS and we need to defer to another technology, like JavaScript?

My Experience

I started thinking about this when I was designing a UI with a lot of logic going on. We had a busy table where we show some additional columns at wider screen resolutions. At smaller widths the user would be able to toggle between different groups of columns and save a preference. But then these additional columns are only offered if they contain data. So, we had logic around the screen width, user preference and presence of data, which, multiplied out, meant 8 permutations.

I initially tried to do it all with CSS. I set up media queries for the narrower and wider screen widths. Within each of these I then read a class for the user preference and then I used :empty to see if table cells contained any data. I managed it and it worked. Just.

However, I realised that it was really not scalable. Every time I added a new condition it doubled the amount of CSS I was having to write. If we wanted to add more logic in future it would create more and more work and be harder and harder to maintain.

By moving all the logic into JavaScript we can set simpler classes, one for each type of display we need rather than every permutation of logic. So now we just have 3 classes: 1) show the first set of columns, 2) show the second set or 3) show all columns.

We still have lots of branches in our JavaScript but the big difference is that it’s easy to read and follow. It’s also easy to edit or extend if we ever need to.

I think doing some logic with CSS is fine but as soon as you’re starting to layer it on and find yourself multiplying out the selectors you’re writing it’s probably time to move it over to JavaScript.

Clicking Off Things to Close Them

There’s a common design pattern these days where a bit of content is shown over the main screen. It might be a modal window or maybe a fly-in menu or sidebar. It’s also common, especially in native apps, that we can just click or tap in the space not used by these elements to close them. So, how can we do this?

I think there are 2 approaches, one which is pure JavaScript and another which involves an overlay element. Let’s look at both.

JavaScript Document Click Event Method

We can detect that a click is not on the content element using JavaScript. As all click events bubble up or propagate through the DOM tree they eventually reach the top document level. We can listen for a click on the document and then use the event target to check what was clicked. For this example let’s assume our content element has a class of ‘modal’, like <div class=”modal”></div>.

// JavaScript

function handleClick(event) {
  if (!event.target.closest('.modal')) {

document.addEventListener('click', handleClick);

event.target gets the element that was clicked. This could be the modal element itself, another element inside it or another element outside of it. event.target.closest(‘.modal’) checks if the element clicked is the modal or is an antecedent of the modal element, an element within it. If the element clicked is not (!) in the modal we can close it.

It’s maybe worth noting that .closest() doesn’t work in IE11 if you need to support this but there is a polyfill available.

Using an Overlay Element

The other approach, and the one I tend to use, is to use an overlay element. This means adding an element that covers the whole screen area, slipped in between the modal and the main screen content. The idea is that this overlay will appear and disappear along with the modal and will pick up any click events which are not on the modal. It’s a bit like a safety net that will catch any stray clicks.

The CSS for the overlay would typically look something like this:

/* CSS */

.overlay {

.modal {
  /* styling */

The overlay has fixed display and goes to each edge so it fills the screen.

The overlay has z-index set to 1 so it’s over the main screen content, and the modal has it set to 2 so it’s over the overlay. These can increase as needed but the modal always needs to be higher.

I’ve given the overlay a background colour and 50% (.5) opacity so that it veils the main screen content underneath giving the modal a “lightbox” effect but these are not needed and our overlay can be effectively invisible.

You then just add a click event to the overlay which will close the modal and hide the overlay.

The reason I like this approach is that by covering the main screen we prevent any interactions with it. If the user tries to click on a button under the overlay their first click will just close the modal. We don’t need to worry about any other interactions – while the modal is showing it becomes the sole focus.

Extra tip. If you use a visible overlay it’s nicer not to show and hide it immediately but fade it in and out with a transition on the opacity, taking it between 0 and .5. This feels much smoother and less jerky.

Tips for Working from Home

I’ve been working from home 2 days a week for a few years so thought I’d share a few tips. These are little things that work for me – they may not be for everyone.

Get Showered and Dressed

It sounds obvious but don’t slouch around in your pyjamas. You need to make a work day different from the weekend and any little things you can do to create this clear separation will help your work-life balance and ensure you’re in the right mindset, both ways.

Set Start and End Times

Don’t try to be too flexible with your hours. Stick to a normal working day. Don’t slack off and think you can catch up later in your own time, and don’t do extra to overcompensate for being at home. You need clear times when work stops and home life starts. It’s very easy to get sucked in to “just finishing off this bit” and still be working hours later.

Find Multiple Locations to Work

If you’re working from home for several consecutive days it can help to vary where you work. I wouldn’t keep moving in one day but maybe start every third day in a new spot. For some people having a fixed work space within their home helps the separation so if this works for you, great.

Finding a Good Work Space

For me it’s important to be near a window. I actually work sitting in a bay window looking out onto my street. This naturally makes me look up from my screen from time to time as people pass by. My sleepy town isn’t interesting enough for this to become a distraction but I appreciate this may not work somewhere busier. I would avoid spaces with no natural light, like lofts or basements. They’re just not good for your state of mind.


Set a start and end time for lunch as you would in an office environment. If you don’t, you risk not finding time at all, not taking a break or the day becomes one continuous snack-fest, which is not going to end well over a sustained period of time.

Managing Costs

If you’re home alone, do you really want to be heating your whole house? Or, if you’re lucky enough to be somewhere warmer, using air-con? I try to stick to being in one room, close the door and use a portable heater. This saves a small fortune on my heating bill.

Think about the money you’re saving on travel and put it aside for something which improves your home working lifestyle – a comfy office chair, a desk fan, a fancy microphone, a coffee machine.

Balancing Non-work Activity

Working from home does bring some advantages. You can have goods delivered. You can have the washing machine or dishwasher going. My tip would be to not worry about the small things like answering the door, putting a load of washing on – things that take a trivial amount of time. You should avoid the tasks that take longer and can be left until after work – online shopping, folding washing, cooking.


You’re at work. You can ignore the door. You can ignore your phone. Don’t use social media, unless it’s work related.

Don’t Get Isolated

If you’re alone for a period of time it’s easy to start to feel isolated. When working from home you need to make extra effort to communicate with colleagues. Try to make the effort to actually talk to people rather than just using email or messaging services like Slack. You won’t run into colleagues in communal areas, like the office water cooler or kitchen, so, if a few of you are working remotely you may need to create your own virtual spaces where non work related chat can happen to stay connected on a human level.

What Works for You?

Everyone’s different so do what works for you and if you have any good tips of your own please share.