Skip to content


Web Dev roles

Now that I’m looking for a new role in web development, here’re some thoughts on the types of organisations I’ve worked with over the years.

I’ve worked in a fair few different environments over the years, from corporate to agency and freelance. Each unique, with their own set of business and organisational challenges–not just the technical site of things–and their own solutions for those challenges.

I’ve had a few fairly long stints in corporate (or corporate-light) environments covering for almost a decade of dev time. I honed skills in process, standards, requirements gathering. All solid take-aways that are part of every project I’ve worked on since. As a sometimes-freelancer on the side, the most frustrating aspect of these larger organisations has sometimes been speed of delivery. Even within the framework of Agile process, once a project is rolling, pragmatism quickly wains, change is not really encouraged, and they often roll and roll for a long time. Meanwhile, this business moves fast. Blink and the flavour of the week technology is… what is that thing? As a freelancer, you often own the technology stack and delivery. Because you own the agency of change, you can change. Experimentation is built in, if you let it.

For a subsequent role, I quite deliberately approached a digital agency. I wanted to step outside those somewhat walled environments.

I was lucky enough to step into a lead role at a lovely digital agency in Leith. It was everything I needed: a fluid environment of fast moving projects (for the most), each project a new opportunity to improve on approach and technology and apply Agile techniques, introduce standards and work with fantastic clients.

Teamwork is everything when deadlines and looming and the client is eager.

Aside from that great portfolio of clients (the good, bad, and ugly, but always something to learn) and technology stacks, the biggest take-away from working in an agency environment was the team. I’ve worked with some brilliant people over the years, but for the first time I discovered the teamwork sweet-spot: cross-discipline, client focused, delivery focused and pragmatic. Teamwork is everything when deadlines and looming and the client is eager. The trend to compartmentalise, to specialise too far–something I saw time and again in larger companies–always felt somewhat broken. A developer is not only a developer. A designer is not only a designer.

So, the logical next question is: would I take a role corporate environment again? The answer is: of course. The chance to take the learning’s from digital agency work back into that sort of environment also also attractive.

So here I am again, after 3 amazing years, looking for a change.

So here I am again, after 3 amazing years, looking for a change. It appears many larger companies have learned some of the above and run “internal startups”, perhaps a best-of-both-worlds, and attractive. Edinburgh has a fantastic start-up scene too. I’ve been really lucky over the past week to meet some fantastic teams across the city and it’s exciting. It’s refreshing.

Lets see where this goes.

Looking for a web developer? My LinkedIn profile is here.

Update, October 2017:

After a few weeks hunting around, Cally from  fashion start-up Mallzee pinged me. A really fun crew with a fantastic app, looking for a front end developer, like me. After a few visits to their office, I’m pleased to say I’m now part of team Mallzee building front end for fashion webapps and dashboards… and who knows what in the future. Exciting role in a vibrant company.

Live-blogging and Micro-blogging

Exploring microblogging directly from WordPress. I’ve found this style of blogging really useful when working through a problem; a worklog/devlog of sorts so I can retrace my steps (those not covered by git commits).

This looks promising:

For live blogging I also found this free (open source) project.

Screenshot of LiveBlog splash page

My only fear with introducing yet another 3rd party service is over-all reliability.


Renewing SSL with crontab failed

LetsEncrypt SSL certificates expire every 90 days.

Looks like something not quite working with the auto renewal of SSL certs for my person domains. Caught an email from LetsEncrypt warning me that various domains were about to lose their certificates, despite a cron job running on the server.

To edit the crontab (Ubuntu):

 sudo crontab -e

Which now reads:

0 4 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log

Updated cron to run on Mondays at 4am (using this handy cron calculator).

For reference…

sudo /usr/bin/letsencrypt renew

…will manually renew any certificates that are about to expire.



Deeply nested tables that are purely for layout. Horrible inline styles. He must be building emails…

The problem remains legacy email clients, and the bizarre long tail of support that results in. While desktop browsers have moved on and it has become relatively acceptable to focus support on “evergreen” browser, this move is happening much, much slower for email clients. The result is sprawling legacy code like the screenshot below.

Honestly. We don’t need to support Outlook 2013 do we? I can only imagine (with zero evidence, natch) that anyone still using broken HTML rendering mail clients like Outlook 20XX are doing so because they are in a corporate environment where they are not allowed to update or change their mail client.

But here’s the thing. Most of the clients I’ve worked with are commercial… public facing. How many folks are really using their corporate email client to read personal emails? I certainly wouldn’t be picking up emails from my personal accounts in a locked down environment. I imagine in many environments this may even be against company policy in the first place.

I do most of my email reading on my iOS devices, and it makes me cringe when I look at the size of some of the emails I receive: 90% (possibly another made-up figure) layout crap to support other email clients—clients that almost nobody uses outside of locked corporate desktops.

Modern handhelds have very good HTML email rendering. gMail even supports responsive emails now.

So can we please make this stop?

Screenshot of email markup
Email markup hell


My host (Digital Ocean) provides weekly full-server backups, and I can snapshot on the fly before I make any dramatic configuration changes. But this isn’t really fine-grained enough for a production environment.

Finally got around to doing something about that. All of my code is in GitHub, so I’m only really worried about content – and for that I needed a good, simple solution for WordPress. A place to start at least.

I came across the excellent UpdraftPlus plugin for WordPress, and after some fiddling around, I got it working nicely with my Google Drive account. Initially I wanted to use Dropbox, but frankly Dropbox’s free space is pitifully small. In an ideal world I’d connect any backups to Apple’s iCloud storage… after all I’m paying for a terabyte of it. Sadly, none of the services I looked at support that. Apple! Google Drive with 15Gb storage to the rescue, via the creation of an API key and authorising my web server, the backs are running smoothly.

Not that I’ve tested them yet.

…that’s for another weekend.

Split personality…

Writer Me likes to hang out with fellow writers, share fun links, talk about the process. There’s a lot of  hair-pulling and alcohol involved. Developer Me likes to chat tech with fellow developers, share experiments and talk workflow. There’s a lot of hair-pulling and alcohol involve.

I tend to do most of my tweeting from @shellbryson. This leads to a problem: there are two sets of folks I’m interactive with and 1) when I’m on a roll with writing I’m posting a tonne of writing things 2) when I’m deep in code experiments… Basically I need to pick an audience and stick with it. It’s a marketing thing (sigh).

Yesterday I created a new Twitter account dedicated to Developer Me@sherucode.

Banners and Avatars

New account, new art. I like my wee “sheru” Chibi—a left-over from working with the wondering AnimePicks team a few years back—but the avatar never really fit the developer me. Definitely not the writer me.

Cartoon image of Shell (Sheru)
Shell (Sheru) Chibi

Head scratching, and with zero time to do a full brand, I opted for something playful, but… code-y. What better than to use what I have to hand? Shot with an iPhone, retouched in PhotoShop:

Photo of Lego minifig.

Twitter likes a big banner, so I took another photo of what was literally in front of me… my keyboard. Then off into PhotoShop. Layer masks, blurs and radial fills and masking of letters and we have:

Retouched photograph of keyboard

It was fun to spend some time with PhotoShop again. Working for an agency means I tend to be given designs to implement, rather than having and hands-on during the design process.


Another crazy week as we get into the final few days before launch of a big new financial site at the studio. Meanwhile, I’ve managed to calve out a little time to play with React. I still have an issue with JSX and inlined CSS. It feels like a backwards step, mixing structure, JS and CSS together. All that careful separation of concerns that have been hard-fought over the years seem to somewhat fall aside when it comes to some of the modern framework.

Thing is, React is great. It makes a tonne of sense. It’s really cool to work with.

I’m still unsure how I’d fit it into a project where I care about rendering when JavaScript is not available. I also worry about page weight, given the lump of script that needs to be delivered with a React project. There are of course ways around this—loaders, server side rendering with Express—and certainly as web sites become more ‘app-like’ I expect to see more and more React based sites. The danger though comes from using React (et al) for sites that could be built far more simply using a standard technology stack. Not to mention easier to support.


Manic week at work as we get closer to the release on a big financial site (hence the severe lack of updates here). Took some time out tonight to do some housekeeping.

Finally got around to adding IPv6 after reading various press regarding the increasing scarcity of IPv4 addresses. It’s a little more fuss to setup, but seems to work. Not that I can hit IPv6 addresses from this cable network…

While tinkering with the server, snapshotted, updated and patched everything.

A week ago I added Digital Oceans’ new monitoring beta tool, and it keeps bugging me that this server is using over 60% of its memory. Which doesn’t match what the memory monitor itself tells me on their admin panel. Something else to investigate…

Virgin Media were around today so we have a new 8-tuner set-top box and 200mbit internet. Long (very) story short, it’s taken 6 months to get a new modem from them. But hey, now we have the top tier TV and funky new 8-tuner set-top box too.



There’s nothing like the crunch at the end of a project to find out which processes are really working for you. Agile is a great methodology for approaching a project, but it can easily (and frequently, in my experience) lead to “ticket overload”. This is especially apparent at the end of projects where throughput of tickets is critical as the project rushes towards a hard deadline.

So why the deluge of tickets? Perhaps it’s a sign that something didn’t work earlier on. That QA were onboard far too late, or poorly scoped tickets or poor executed code. Overly ambitious requirements, or fiddly design. All of the above. And some of that is just natural entropy in a project-especially the long run ones where process expands to fill all available time.

It’s not always hard. We’ll do better next time. But sometimes we forget that process is there to help. Not strangle. We forget that we should be hungry to deliver, and delivery is more important than process.

Given a week to deliver something, you find a way to deliver. Any away, whatever it takes.

Given three months to deliver something, process finds a way to trip you up.

I believe in release often. Release small. Real deadlines. Real opportunity for the client to see something to feedback, to catch those changes and design glitches, the bad code or trippy UX. Release every week, twice a week, every other-day. Sit the client down and walk them through it. Show something. Be cool with what you’re showing them. It’s work in progress.

Real agile is iteration. Not invisible sprints without consequence or comment. Breaking a waterfall project into sprint and calling it agile is not agile.