Delib has around 30 people in total.

We build and operate platforms for democracy.

10 people work in product engineering. Product engineers have specialisms, mostly as software developers, but we also have specialists in QA (quality assurance), interactive design and product management.

I asked 5 of them some questions.


…there’s not really such a thing as a true programmer or developer anymore…you have to work at the product engineering level most of the time.

Adam – Product Engineer

How long have you worked at Delib?

Adam: ~3 years.

What other jobs have you done?

Adam: way back I was a graphic designer for a while.

I’ve also worked (as a developer) for standard web agencies, digital ad agencies, and more recently more product-focused companies.

What are the most memorable things you’ve learnt since starting at Delib?

Adam: I think there’s two distinct areas where I’ve learnt a lot at Delib;

Firstly design. Designing a new feature from scratch, building it, user testing it (via sweatboxing).

Then releasing it across the fleet, getting further feedback, making improvements.

That whole life cycle was something I’d not been a part of from start to finish before.

There’d always be at least one area that’d be handled in a blackbox elsewhere.

Secondly accessibility.

Before working at Delib I was looking at accessibility in a very superficial way.

Due to the nature of Delib’s products, over the last year or so, I’ve really taken a deeper dive into that, and it’s been really rewarding.

What’s your hardest-won lesson about product engineering?

Adam: I think really it’s that there’s not really such a thing as a true programmer or developer anymore.

You have to work at the product engineering level most of the time, i.e. have your head in the bigger picture, the road map and the usability all at the same time. I think this is really why the term ‘full stack’ came into use partly.

What do you wish someone else had just told you about product engineering?

Adam: hmm.

To make data driven decisions rather than either thinking you know what users want or relying on someone else to make up some opinion about what they think users want.

How do you know when something’s good?  What’s your measure?

Adam: It’s always about the users.

If the users are happy, then we’ve won. It’s very difficult to know if something’s good whilst you’re building it.

And QA (quality assurance) of course. The QA process at Delib is excellent, probably the best I’ve worked with.

What bothers you about the widely-used term ‘full stack developer’ (if anything)?

Adam: ha

I mean, nothing at the moment.

It used to bother me, but now I just see it as a synonym for ‘engineer’

It’s weird that capitalism has allowed this role to become more generalised rather than keeping it specialised. Sorry, going off on a tangent there.

Short answer is – it doesn’t bother me much anymore.

Any recommendations of things to read / listen to?

Advanced Python Development by Matthew Wilkes ;D


…beautifully designed systems don’t stay that way long in the real world.

Shaney – Product Engineer

How long have you worked at Delib?

Shaney: just over 3 years.

What other jobs have you done?

Shaney: I worked for around 7 years at Sift/PracticeWeb. That was on creating and maintaining a platform for accountancy websites in Drupal/PHP and a little Java.

After that I worked for around 3 years at a web agency called Positive. We built and maintained websites and sortware for a variety of clients with a focus on the third sector (charities and voluntary organisations).

What are the most memorable things you’ve learnt since starting at Delib?

Shaney: hmm, good question. Let me think

On a technical level, I’ve learnt a lot about design, and deeper implications of decisions when dealing with large, long running systems with a wide user base. I’ve learnt a lot more about management tools for those systems.

On a human level, I’ve learnt that most of the actual work comes from how software interacts with people.

And that people are the hard part of the equation.

But also are the whole point.

What’s your hardest-won lesson about product engineering?

Shaney: Never assume it’s as simple as it seems.

Never.

What do you wish someone else had just told you about product engineering?

Shaney: I’m not sure. Most of the things I’ve learnt, I’ve learnt better because I’ve found them out for myself.

Not Delib related, but in general: (to me in university) no software looks like the stuff you create in university, beautifully designed systems don’t stay that way long in the real world.

Some one did once tell me: “no-one’s going to die, it’s just software, it’s not worth crying over.” That was very helpful.

How do you know when something’s good?  What’s your measure?

Shaney: Mostly, when it’s 6 months down the line and people aren’t having to think too much about it.

Either it’s doing its job quietly, or at most people think “I’m glad we have that tool now”.

Any recommendations of things to read / listen to?

Shaney: not much that’s actually software related. I like podcasts like Adam Ruins Everything because they make you think about misconceptions.

And things like 99% Invisible that make you think about design and how it interacts with people.

But I mostly listen/read to things outside of software tech. Otherwise I’d be a very boring person/quickly become a gibbering heap.


Don’t be frightened of calling ‘stop’ if something starts to go wrong.

Michael – Product Engineer

How long have you worked at Delib?

Michael: just under 18 months

What other jobs have you done?

Michael: I’ve previously worked as a developer in the telecomms and telematics industries

What are the most memorable things you’ve learnt since starting at Delib?

Michael: don’t be frightened of calling ‘stop’ if something starts to go wrong.

What’s your hardest-won lesson about product engineering?

Michael: if you don’t have a QA (quality assurance) process and documentation then you don’t have a product, you just have an implementation.

What do you wish someone else had just told you about product engineering?

Michael: always collect the data before trying to optimize or otherwise improve code.

How do you know when something’s good?  What’s your measure?

Michael: my measure for good software is when it either enables someone to perform a task with more ease, or when it doesn’t add more friction to a task they are already comfortable with.

What bothers you about the widely-used term ‘full stack developer’ (if anything)?

‘Full stack developer’ doesn’t really bother me, although it feels like an assumption that developers can be expert in everything. Some possibly can, but likely not all.

Any recommendations of things to read / listen to?

Michael: the Google SRE (Site Reliability Engineering) book, also The Wisdom of Crowds.


It’s hard saying “no sorry, our product doesn’t do that and probably won’t” and losing a sale.

Jess – Director of Engineering

How long have you worked at Delib?

Jess: 14 years.

What other jobs have you done?

Jess: freelance PHP development and a very short stint writing developer tools for a games company.

What are the most memorable things you’ve learnt since starting at Delib?

Jess: engineers’ guesses of what the customer needs are often not that good.

Also, customers’ guesses of what the product needs are often not that good.

You need someone (product owner, experienced account manager) to glue those guesses together.

What’s your hardest-won lesson about product engineering?

Jess: just because you can build something doesn’t mean you should…

It might make you feel good or make a customer happy in the short term, but in a long-lived software product every line of code you write has to be supported, tested and maintained for a long time.

And it’s very difficult to retract features once they’re there.

What do you wish someone else had just told you about product engineering?

Jess: you need to have the right tools and data to hand. You need to know how people are using your software, and how the software is behaving (goes back to the “engineers’ guesses are not always that good”).

How do you know when something’s good?  What’s your measure?

Jess: If you’ve just deleted a lot of code, that’s probably good.

(Chesterton’s fence notwithstanding).

If you struggle to explain something or have to justify it when sending it for code review or QA, then it’s probably not good.

I often find that just writing the notes to another engineer on a PR (pull request) is enough to tell me it’s not yet ready for code review.

We do lots of things to try and make product engineering a sustainable rewarding job that gets results.  Pick your top 2.

Jess: autonomy. Engineers at Delib generally don’t get told how to do something, or even necessarily what to do. We all have a lot of personal ownership of our products.

And trust…

Gah words.

More or less “the rest of Delib trusts us (I hope) and we trust each other to be capable and to give a shit”.

The software industry has lots of unfortunate habits.  Name one that we took too long to drop, why was it hard, how did we do it, and what was the upside?

Jess: Nice question.

It took us a long time to get to the stage of selling a standard product. Even after we thought that’s what we were doing, we liked to say “yes” to customer-specific requests (who doesn’t?) without thinking about the long term implications…

…but custom deployments (are we allowed to say ‘snowflakes?’) frequently cause fires, lost time, lost money.

It’s hard saying “no sorry, our product doesn’t do that and probably won’t” and losing a sale.

Name a bad habit that we know we need to drop, why is it hard, and what do we predict the upside would be?

Jess: silos between groups of people in the company. We try hard not to refer to people by their job “the account managers”, “the devs”  but it’s an easy shorthand. We can’t build good products in isolation.

This is actually getting harder now we’re all working remotely and don’t cross paths in the kitchen.

I don’t know how we can improve things but we do need to.

Any recommendations of things to read / listen to?

Jess: the Poppendiecks’ Leading Lean Software Development is a classic. And cheesy 90s trance on your headphones when you want a productive day of head-down writing code 🙂

What bothers you about the widely-used term ‘full stack developer’ (if anything)?

Jess: I don’t mind the term as much as you do I don’t think, but I find it hard to believe that someone can be equally good at (or interested in) all of it. I think people need to be at least tolerably comfortable working in all parts of the stack though (especially when you have to do support).


…abstract user stories don’t send sad emails.

Alan – Director of Engineering

How long have you worked at Delib?

Alan: coming up to 13 years.

What other jobs have you done?

Alan: this was my first full time role out of university. I’ve also run a company specialising in Python application security and performance for a few years along with the odd freelance job here and there.

What are the most memorable things you’ve learnt since starting at Delib?

Alan: technically, that implementation and tooling stability pays massive dividends over longer application lifecycles.

Non-technically, that the implementation is a relatively small part of a successful product and that there’s a huge skillset involved in delivering that.

What’s your hardest-won lesson about product engineering?

Alan: hmm, limitations of practicality aside, it can’t be entirely led by the technology.

What do you wish someone else had just told you about product engineering?

Alan: I think it’d have been interesting to hear more voices strongly emphasising the importance of how to deal well with failures.

I’m not entirely sure I’d have listened to them though, given so much of the industry is has been traditionally focussed on success.

How do you know when something’s good?  What’s your measure?

Alan: it depends – beyond the objective quality of “does it work” I think ultimately it’s about how tightly the problem is defined and whether the solution is clear in its intent.  I’m not really sure that’s much of an answer :/

We do lots of things to try and make product engineering a sustainable rewarding job that gets results.  Pick your top 2.

Alan: having everyone involved to some degree with the product development/roadmap/lifecycle process makes a huge difference, at least for me, versus more strict product ownership where there’s no meaningful discussion.

I think also having a generally good relationship with customers helps a lot – it’s very easy to build things when you know a real individual who you’re helping versus an abstract user story…

…abstract user stories don’t send sad emails.

The software industry has lots of unfortunate habits.  Name one that we took too long to drop, why was it hard, how did we do it, and what was the upside?

Alan: on the whole we’ve done alright with avoiding the worst of the industry but in hindsight the whole idea that bespoke systems are somehow better for anyone took us way too long to drop – it’s hard because it’s so easy to say yes to largely useless software changes in exchange for money then fool yourself into building processes that make it manageable (for some questionable definition of manageable).

In reality it just sucks all the momentum from the core of the product where you really should be focussing.  Breaking that cycle was a long process and unfortunately part of it really only comes with having enough of a customer base to provide evidence that it’s not necessary.

The upside is it’s better for literally everyone – we can work on the core app, customers get better features faster and we get more customers as the tooling is standard.

Name a bad habit that we know we need to drop, why is it hard, and what do we predict the upside would be?

Alan: interestingly, I think this is one of the last vestiges of having previously done custom project development – our instinctive response to bugs and other production issues is sometimes still to dig in and fix it just this one time for just this customer.

It’s hard to drop because it works, especially where fixes get rolled back into the product for other customers in the next release, but it doesn’t scale – it’s still time spent fixing one individual instance in a fleet of hundreds who could all be benefitting from the same change.

What bothers you about the widely-used term ‘full stack developer’ (if anything)?

Alan: it doesn’t massively bother me, it’s not a bad catch-all term for generalists but I think it downplays individual specialisms and preferences which do ultimately matter more if you want a performant team.

Any recommendations of things to read / listen to?

Alan: heh nothing specific that wouldn’t also be covered in a thousand other reading lists, although I find that anything about making and operating _things_ (and the associated failures) outside traditional software engineering provide by far the most useful insights (eg how to build satellites and why boats sink or planes crash).


Coda

Fancy working with us? We’re probably hiring.