DEV Community: James

To React or Not?

James — Wed, 24 Apr 2019 21:30:47 +0000

We're building a SaaS platform at work and have a choice of JS framework to make.

In my last two roles leading dev teams we had similar choices to make and shortlisted React, Angular and Vue. In both teams, we decided (democratically) to select React as our framework of choice and merrily cracked on with that.

I won't bore you with the reasons why, there are a million posts about which framework to choose, and we referred to some of these, set our own criteria of importance and then reviewed and rated each of the contenders before voting.

But, crucially, this was before Cambridge Analytica, the undermining of democracy and live streaming of murder.

Re: Angular, Google also has issues regarding some of its practices, (maybe this is just a defining characteristic of tech unicorns?), for example regarding content on Youtube, if you can monitor and take down copyright infringing content surely you can monitor content designed to spread hate and fear?

But, is it fair to level criticisms of the creators of these tools and frameworks at the tools and frameworks themselves? To put it another way, can you separate the creator from the creation?

What if we take an analogy from art? Whether or not you consider software development an art form (which is an interesting but wholly different topic, let's leave that for another day, or perhaps a dev discuss?) it doesn't matter for the purposes of this comparison; can you separate Michael Jackson's music from Michael Jackson?

It can be easily argued (especially given the recent documentary) that you can't, and there is a very clear case for boycotting his work, at least not providing further remuneration to his estate for this anyway. (Can you listen to a 2nd hand copy of one of his CDs though?)

Can the same be said for use of a software tool or framework? Even if that tool is open source by using it are you lending support to that software, and so by extension to its creator?

Can, or more importantly, should the behaviour and/or practices of the creator of a piece of technology be a criterion for selection of this technology?

And if we do, what weight do ethics have on selection, is this on an even footing with say community support, potential talent pool, extensibility, learning curve, or any other criteria you may choose?

From a purely pragmatic point of view, my head says weigh up the needs of the team, company and users and make the best practical selection, but it doesn't feel right, technology doesn't exist in a vacuum, it is increasingly interwoven in our lives and if we are concerned with improving user's lives through better technology, shouldn't we who are in a position of choice make an ethical one?

What are your thoughts on the ethics of software selection, am I just indulging myself, does this chime with anyone, would love to hear what the community thinks.

Thanks for reading,
James

Applying a Naming Convention to Constraints via SQLAlchemy & Alembic

James — Thu, 14 Feb 2019 10:56:42 +0000

Top Tip!

So we're creating a new database schema, using SQLAlchemy for the ORM and Alembic for the schema management, (if you use Python and need to manage a database sructure I highly recommend these two tools), anyway we just ran into a problem when downgrading a migration that attempted to drop an unnamed Foreign Key.

Wat?!

Why would it allow me to create a constraint that it can't drop, why? Good question, turns out that it's up to you (well me in this case) to name things.

Obviously we don't want to have to remember to do this manually everytime we generate a migration involving a constraint, that would be tedious and prone to error (I will definitely forget to do this), so what do we do?

Well Alembic has you covered, you can set a naming convetion to apply to all migrations, when declaring your Base model class (this should be default behaviour in my opinion, but I'm not hating, nothing but love for you Alembic/SQLAlchemy).

Cut to the chase and tell me how

Well like this;

from sqlalchemy import MetaData
from sqlalchemy.ext.declarative import declarative_base

meta = MetaData(
    naming_convention={
        "ix": "ix_%(column_0_label)s",
        "uq": "uq_%(table_name)s_%(column_0_name)s",
        "ck": "ck_%(table_name)s_%(constraint_name)s",
        "fk": "fk_%(table_name)s_%(column_0_name)s_%(referred_table_name)s",
        "pk": "pk_%(table_name)s"
    }
)

Base = declarative_base(metadata=meta)

Source alembic docs for reference are here thank you alembic peeps!

So there you go - simply use the Base in your alembic env.py - and also inherit from Base in all your model classes and you're good to go

You'll see autogenerated migrations like this;

    ...
    sa.PrimaryKeyConstraint('id', name=op.f('pk_thing'))
    ...
    sa.ForeignKeyConstraint(['wotsit_id'], name=op.f('fk_thing_wotsit_id_wotsit')),
    ...

Enjoy!

Engineering Team Manifesto

James — Thu, 31 Jan 2019 16:56:33 +0000

The time has come for me to move on from my current role, and as is frequently the case when changing jobs this situation provides an opportunity to reflect on things, what went well and not so well and how I will approach the next opportunity.

One of the things I am most proud of from my time at Airfinity (and there are quite a few, not least of which is the amazing team I worked with, props to you guys) was the culture of the engineering team we set out to build and achieved.

As the first permanent engineering hire I was responsible for hiring and building out the team and our capability and the first thing I did was to sit down and think about the culture I wanted the team to have, the type of team i wanted to hire and work with, the kind of thing you don’t often get the chance to directly influence.

To ensure I had a point of reference I wrote this down, and looking back on it now it strikes me that this was in some way a manifesto for how I think technical teams should be, so I thought I’d share it with you here, because not only is it something I firmly believe in and that we should all aspire to, it was something we achieved and I am immensely proud of that, so here it is.

Engineering Team Culture

The culture of a team is one of the major factors influencing how enjoyable work is, it is vital that as we grow we nurture and retain a supportive, collaborative and enjoyable team culture.

This manifesto outlines a few main points that we would like to define our engineering team culture, it has been put together by the team lead with consultation and input from all members of the company.

We are all Product Engineers, not Software Engineers.

The distinction is important, we must all contribute to the definition of features and direction of the product. If we have empathy for our users we will create better products, everything we do should be aligned with the strategic goals for our products and company.

There are no stupid questions.

If you have a question, just ask. You will not be ridiculed or made to feel bad for asking or checking something. We must all prefer to answer a question to help keep work moving or clarify an issue than have someone struggle because they are reluctant to ask.

We strive for clear and frank communication.

When we stop communicating we are in danger of doing or building the wrong things, we must all keep informed about what we are working on (hence our stand ups, estimation, etc)

BUT - a brief conversation > an hour long meeting

Strive to communicate clearly and often, avoid expensive team meetings where possible (leave those meetings to the team lead if engineering must be present)

We will remain as flat as a pancake.

There is no hierarchy, there are however variations in depth and breadth of experience.

We should celebrate our differences and remember that we are greater than the sum of our parts, rather than adhere to a layered hierarchy.

We are all Product Engineers, it’s just that some of us have different areas of specialism and more or less context to the company and technical stack.

Everyone is able to work on any part of the technical stack.

We’re not saying that we want homogenous skill sets, as that is unrealistic, but we do want the ability to share the work across the team (via mentoring where needed) for multiple reasons;

It keeps things interesting and provides learning opportunities

It fosters a culture of knowledge sharing, preventing knowledge silos

It means that we can take holidays without fretting about something back at work

We actively encourage learning and development.

We want to build and maintain a team that enjoys learning new things, this growth mindset must be a key trait of team members.

Learning new technologies and techniques increases our value to the team and improves the products we build as well, it also motivates team members and helps drive innovation

Build, test, deploy, review, iterate.

Better to ship a feature quickly and review its usage/impact than to fuss over every possible edge and side case and take forever.

We can always iterate a feature, but we won't catch every edge or side case upfront so ship it and review

Long running tickets cause bottlenecks in delivery, ship and move on, raise a new ticket if needed

Deploy your own code, and sometimes other people’s!

We are all responsible for deploying our own features, unless unable to or it makes sense for someone else to do it

Sometimes it is helpful to deploy others code, and from other areas of the technical stack to your usual responsibilities, this helps share knowledge and workloads

If you broke it, you fix it.

Related to the above two points, bugs happen, if we don’t break a few things then we aren’t moving fast enough

BUT, if you break something by deploying your work, you have to fix it.

Of course your team-mates can ridicule you for the bug/all help out to resolve the issue, you will never be on your own when this happens

Have fun.

What’s the point of all this if we can’t have a bit of a laugh?

Let’s try and have fun whilst we work and if it’s ever not fun, please let your team lead know so they can try and fix things/address any issues

In summary

So there you have it, reflecting on this document (written nearly 2 years ago) I feel like we achieved this in our team, so I’d like to preserve this here for future reference and as a reminder that a supportive, collaborative and fun work environment is achievable with a bit of effort and perhaps also some good fortune regarding the organisation and context you are a working in.

I’ve worked in tech for twenty years and sadly this kind of environment has proven to be the exception, but I will do my utmost to ensure this culture prevails in all of my future roles and teams, I hope this inspires you to try the same.

Thanks for reading,

James.

Originally posted on my blog

The 'Just' Jar

James — Tue, 05 Dec 2017 10:58:30 +0000

I thought I'd write a quick post to describe one of the little tweaks we recently made to our development process here at Airfinity.

Our dev team works in month long sprints at the moment and we generally take a day to estimate the top of the product backlog as a team, this is then used for a final re-shuffle of priorities by our product owner before we crack on and start building things. Of course things change over the course of the sprint, and we roll with that, the most useful information to facilitate this agility is reasonable estimations of size, complexity and duration.

One of the most common and dangerous words that I have heard when estimating or discussing software features, especially when discussing these with non-technical parties, is the word 'just'.

Many articles have been written on this so I won't bore you with why, if you build things you'll know what the problem is, but for reference two good muses on the topic are here and here.

So to combat our use of the word we set up a swear jar*, or Just Jar^tm as we like to call it. Every time one** of our dev team uses the word just we cough up a pound, the proceeds of this will go towards extra drinks at our Christmas bash.

It's a fun way to game behaviour and slowly change it, it helps us clarify our thoughts and think through estimation a little more to ensure we allow enough time, and it's fun calling people out. Plus we have about £30 in the jar after our first month, so it's pretty lucrative!

I suggest you give it a try, let me know what you think or how you get on in the comments.

James

*Obviously we still swear every now and then, the odd expletive is ok as long as it's directed at your own code.

** Edit: I should point out that I am possibly one of the worst offenders/highest contributors, but hey you lead by doing right?