DEV Community: Dan Silcox

Sharing knowledge well

Dan Silcox — Thu, 24 Oct 2024 10:48:16 +0000

Overview

Over the years we all learn a lot of 'stuff' and some of it is more intricate than others. For many of the day to day things we may do at work, it is a good idea to automate them, or eliminate them by finding better solutions. Sometimes however, there are complex workflows that can't easily be automated, or where the return on investment just doesn't justify the work to do so.

At the same time, we all know how risky it can be for the individual and for the business when there are SPOFs controlling or even hoarding knowledge, whether they do so intentionally or not.

So in those cases, how can we ensure that the person with the complex workflow knowledge (including the 'why', not just the 'what') is not the only person that can handle that task?

This is as much a discussion topic as anything, but I'll put an answer below, albeit an incomplete one...

Be a billboard, not a vault

It may be a bit of a cheesy expression, but I feel that title encapsulates the thought behind what I'm trying to say quite well.

In my experience, from the 'knowledge holder' perspective it can be difficult to let go at times, especially if you feel that others might not do the job "properly". But the best thing to do is trust your colleagues and let go. In most cases people will surprise you in the best way.

I've had situations where I've held onto certain processes myself for far too long, only to find that when I do hand them over, the other people actually do them far better than I did and often think of things from different angles, ultimately improving the overall workflow.

For example, I recently had a task to analyse a graph of metrics for the past 24 hours, to ensure the system health was at baseline and we had not missed any alerts. When I looked at it, I sort of mentally compared it to previous baselines and made a judgement call that it "looked about right".

Someone new to the process did the same task the next day, and noticed that the graph was showing 'average' rather than 'maximum' for one of the metrics, meaning we were not getting a true reflection of the metric in the context we needed (CPU usage I think it was). Their fresh eyes unlocked a really important insight, much the way a code review uncovers bugs or flaws in 'perfectly fine' code.

Don’t wait, initiate

From the other perspective, i.e. "the team member who doesn't have the knowledge but should", I have found that most people are only too happy to share their workload, especially when it's for tedious work that needs doing, but nobody really wants to do!

In cases where the knowledge holder does not want to share this knowledge, they normally accept that they should be doing so, and can normally be persuaded to do so, even if slightly begrudgingly. This is normally something that business leaders would be in favour of doing anyway, so if necessary can be escalated (though obviously tread lightly as this can be damaging to team relationships if not handled with care).

Team leaders: consistency is key

In leadership roles it is often one's job to make sure the team have no single points of failure or, at least that these are minimised with some form of backup strategy. One of the tenets of modern agile teams is the concept of T shaped developers, and cross-functional teams in general. This does not mean that every single person must be fully equipped and trained to do every single job; that can very quickly become unmanageable and counter-productive.

It does however mean that there should be a certain baseline knowledge level of all the different aspects of a team, e.g. most or all team members being able to do the basic support tasks required of the team, with maybe one or two team members taking the lead in that area, driving improvements such as automation, or otherwise streamlining processes.

This is why knowledge sharing is so vital to a high-performing team, since without it, silos can very quickly develop and lead to a multitude of pain for the team and the rest of the business, and ultimately, the customers and end users.

The biggest challenge with knowledge sharing is making sure there is consistency in approach, in terms of the actual steps taken as well as the quality / detail level applied.

As a leader it can be tough to encourage or enforce standards like this, but this consistency is key to a healthy and high performing team, so should be valued very highly at all levels.

I have been in teams before where if team member A performed a task it was pretty much guaranteed that there would be rework, build failures (normally because they 'forgot' to run QA locally), and compatibility issues when it came to deployments, but if team member B did the same task, it would have great test coverage, work flawlessly, and be forwards and backwards compatible, and even have documentation for how it works (which of course team member A "didn't have time" to do).

The team themselves should be enforcers of their own standards, whether that's during code reviews, passing tickets back to individuals who 'forgot to run QA', or whatever else. Generally, the person in question will start to improve their habits just to avoid the social stigma and rework!

Summary

This has turned into a bit of a ramble, so here's the short version:

As a knowledge holder, be open and honest and willing to share your knowledge as it not only helps the team, it actually helps you!
As a team member or knowledge 'seeker', offer help and most people will bite your hand off for it!
As a team lead, when encouraging knowledge sharing, ensure consistency is key and try and get the team to enforce this themselves; if it's 'top down' driven, it won't be nearly as effective as if it's peer-to-peer.

Over to you

Are you a developer, tech lead or in another relevant technical role? What are your thoughts on this topic? I'd love to hear some good tips for knowledge sharing both from the 'sharer' and 'sharee' perspectives, as well as from a leadership standpoint.

Starting something new

Dan Silcox — Thu, 05 Sep 2024 22:24:10 +0000

Intro

I have had quite a varied career in and around tech over the last 10 years or so, working on varied tech stacks in many very different companies in terms of size, structure and even budget, as well as doing a stint of freelancing.

In the hopes of it being helpful to people earlier in their career, or looking to advance to the next level, but without sacrificing a whole lot of their 'life' outside of work, I've decided to share some of my stories, knowledge and the things I've learned over that time in the hopes of helping others to learn from my mistakes and avoid making them for themselves! I don't presume to be an absolute expert but I definitely have some things to say that could be interesting, useful, or preferably both!

This post is essentially just a vague high-level introduction to what I'm hoping to make into a bit of a series, so I won't go into loads of detail here, suffice it to say my goals for this emerging project (or whatever this is) are, in broad terms, as follows:

Pass it on

Over the years I've had the privilege of learning from many smart people, and doing some cool things. I want to share some of that acquired knowledge and wisdom in the hopes of elevating others and providing something of a platform for them to build upon in their own growth journey.

Be a human first

There's a lot more to being a good developer than the code we write, whether it's the interactions with other people, our mindsets around the work we're doing, or even our own physical and mental health.

Build in public

This post itself is an example of this. I don't really know what this project is yet, but by posting this, hopefully it'll inspire me to keep going and develop it into... something?!

What's next?

To be perfectly honest I'm not quite sure yet. But I'm aiming to share more details, possibly in video form, at some point in the next few weeks.

If this idea resonates with you make sure you follow me here on dev.to for whatever's coming next!

Performance optimisation - a brief overview

Dan Silcox — Mon, 21 Dec 2020 16:40:30 +0000

Introduction

Earlier in the week I was chatting with a colleague about the HUGE topic of performance optimisation and what can be done to get the most throughput from a system in the most efficient way. I thought there were some interesting points in our discussion and so decided to turn it into a post.

The first thing to mention is that I am not specifically a performance engineer, so there almost certainly will be things I've missed or misunderstood. Also, this whole concept can take years to perfect and with the ever-changing tech landscape, there are always new ways to screw up performance, or to improve it.

However I believe that the approaches mentioned will help scalability and/or performance in most contexts, tech stacks and environments, so with that said, let's dive in!

Get the basics right first

There are a few key things that I believe will make almost any software perform faster and more efficiently.

Only do work which must be done

The first step when optimising is to eliminate altogether anything which you don't need to do - this is sometimes clear cut (e.g. removing a block of old code that has become redundant) and sometimes less so (e.g. knowing what level of logging to output in which environment)

Minimise what has to be handled at run-time

When I say run-time I'm not just referring to runtime as opposed to build time, I simply mean the time during which your customer/app user/consumer is waiting for the app to do what it needs to do. This could mean outsourcing background operations to a separate background worker, parallelising API calls where possible, pre-warming caches or any other number of things to prevent users waiting for things to complete.

Watch your loops

By definition, anything inside the code block of a loop will almost definitely be run multiple times, so you need to be aware of what steps that loop is doing and what they are likely to cost (in terms of CPU calculation, memory usage, time, etc - as opposed to direct financial cost). Generally, loop-based optimisations can be expressed with big O notation - in simple terms:

O(1) means whether there are 5000 items or 1 item in the collection you're looping through, it will take the same amount of time
O(N) means the time is directly proportional to the number of items, e.g. the loop will take 5000x longer if there are 5000 items than if there is 1 item
O(N^2) means the loop will take the square of the number of items to run (in relative terms) - so if looping through 5000 items, it will take 25,000,000 times longer than 1 item!

Where possible, minimise putting "expensive" things like database queries or API calls in a loop if you can; perhaps the API supports batch requests, or perhaps you can convert your many similar where ID = ? queries into a single where ID IN (...) query.

Nested loops also have a reputation for being particularly nasty if you're not careful. The number of "nestings" are effectively the power by which we multiply N in our "big O" function - e.g a single loop nested in another loop (2 layers) is O(N^2) whereas 3 layers is O(N^3) and so on. That's what I mean when I say they are "particularly nasty"!

Cache me where you can!

Wherever appropriate, consider caching data, to avoid further "downstream" calls - bear in mind that cache invalidation is one of the hardest things in computer science, so you need to be ready to manage that increase in complexity if you add caching to your application.

Test, test test!

There is no silver bullet, or magic way to improve performance - so you have to validate every change you make to ensure it has, you know, improved performance...

Start with a base line, no matter how bad it may be - and then re-run the exact same test after each change to see if things have improved - if they have, great! If not, you can go back and try something else...

Important note - you cannot simply test the response times and throughput - you have to actually validate that the app still does what you think it does! e.g. I did some performance tests once where the response time literally went from 200ms to about 30ms and I was over the moon - until I realised that for some reason it had started returning 500 errors which was why it was so much faster!

Architectural perspective

It's not only at the actual code level that optimisations can be made - also look at your architecture. Should you be looking to scale up or out?

Could you split out some functionality into a separate service and focus your scaling on sub-components rather than blanket-scaling the whole app?

Would it even make sense to rewrite your code in another tech stack for your context? Rarely is the answer to this last one "yes" - but occasionally you might want to prioritise a certain attribute of a language (e.g. a faster "cold start" from, say, Node.JS vs .NET Core for an infrequently used but time-critical AWS Lambda function, or better async support for parallel background API calls from Go, vs PHP).

Scalability

It should be noted that there's a difference between performance and scalability, though they are inextricably linked. 12 Factor has some great tips for highly scalable web applications and many (though of course not all are relevant) of the approaches can be tailored to "non-web" apps too.

Summary

I hope this has been useful, of course it's really only scratching the surface and there are countless other more specific / detailed approaches that can be used.

Is there something in particular that stood out to you? Or is there something you feel I've missed? Why not share it in the comments, let's have a discussion and I'm sure we can all learn something!

Delivering a great demo

Dan Silcox — Fri, 11 Dec 2020 16:08:22 +0000

I've been delivering demos and presentations for about 10 years in various forms, to different types of audiences and over that time I've made a lot of mistakes, had a lot of things go wrong and also had a lot of positive experiences. I thought it might be useful to some who have maybe never done demos or only done a handful, for me to share some of my learning over that time to save you the pain of learning those things "the hard way"!

In my experience there are two main things that lead to a great demo:

1 - Know your audience

If you are delivering to a bunch of developers, that will need to be a very different type of demo than if it's aimed at, say, the marketing department or other less-techy stakeholders and it's absolutely vital that you target your audience in terms of the presentation, even if the underlying content is (mostly) the same.

For example, if you've built some tool, for developers you can mention the tech stack, the methodologies/design patterns/tooling, etc etc - but for marketing you can just talk about the functionality and not really go too much into the "magic" that makes it all work.

2 - Prepare before-hand!

It sounds obvious and we've all heard of the "5 Ps", etc! However I still see people doing demos with little to no prep wondering why it was not well received or why they felt stressed delivering it! Some top tips learned the hard way from my experiences in the past:

Consider pre-recording the demo, at the very least as a backup, especially if you're reliant on external factors or shared environments - I've been caught out by changes made by someone else causing my demo to fail in the past and it's frustrating and embarrassing.
Whether pre-recorded or live, run through the demo out loud at least twice (or as many times as it takes to feel confident and comfortable delivering it) before-hand. You might think you can just "wing it" - and you can - but it will be obvious to the audience who was "winging it" and who prepared before-hand, trust me! Note that by default I'm a "winger" and it's taken me a long time to learn that you end up with a better result out if you put more effort in.
If you make notes, keep them as brief bullet points / prompts, rather than reading something word-for-word - also, if you miss a section during the presentation, just move on - don't panic about going back and covering all the different parts. Again, I tend to start rambling when I'm writing notes, but I've found that by having shorter notes, I actually remember more and deliver a better presentation. I still try and make sure to write a few prompts though, so that I don't miss key information.

3 - Stay calm!

During the presentation itself, your heart might be racing and you might be rushing and panicking, but make a point of taking a deep breath and enjoying the process! By taking a breath, you buy yourself a little bit of time to think ahead.

Even if something goes wrong, most of the time people have either been there, or are patient/kind enough to accept that sometimes things happen! A product owner in one of my previous roles used to say "uh oh, someone forgot to sacrifice to the demo gods!" which helps lighten the mood and remove some of the stress and also divert the focus temporarily while you get the app working (or not!). Whatever happens, most of the time it really is not going to be the end of the world - just talk through what should have happened or show a screenshot/recording of it happening previously, if you have that option! I think that about sums up the key points, though there are no doubt countless other things to consider.

If you've got some thoughts on things I've missed, some funny horror stories or successes, or even some recorded demos you'd like to share, why not post them in the comments?

PHP 8 Released! What are your favourite features?

Dan Silcox — Fri, 27 Nov 2020 16:50:19 +0000

PHP 8.0 has finally been released and as a long-time PHP developer (among other things) I'm excited to see PHP maturing and getting some really great improvements. It gets a lot of stick and like any language it has its limitations and annoyances, but it's great for some things and these just make it far better than PHP 7.x (which was already 100x better than PHP 5.x!).

What are your favourite features to the new version? Will you be migrating your production PHP apps to PHP 8.0 straight away or hold off for a bit?

Here are a few of my favourites, in no particular order:

Constructor property promotion

Languages like TypeScript already have this and developers can save loads of time when writing value objects, entities, DTOs, etc:

PHP 7.3

<?php 
class MyClass {
    /** @var string */
    private $thing;
    /** @var int */
    private $otherThing;

    /**
     * @param string $thing
     * @param int $otherThing
     */
    public function __construct(
        string $thing,
        int $otherThing
    ) {
        $this->thing = $thing;
        $this->otherThing = $otherThing;
    }

PHP 8.0

<?php

class MyClass {
    public function __construct(
        public string $thing,
        public int $otherThing
    ) { 
    }
}

Attributes

At last, we can get away from comments that can break applications!

I realise that syntactically they don't look that different to annotations, but attributes are an actual language feature, not a reflection hack. In C# you can use attributes for everything from input filter validation to Open API definitions and I can see much the same thing happening in the PHP ecosystem over time. It just relies on the major frameworks adopting these rather than the abominations of annotations!

The JIT

This will not make a lot of difference for many web apps, blogs, etc, but for backend long-running scripts, CPU intensive operations, etc, this will be a game changer. The graph on the PHP 8 release page shows some examples of how much difference it can make:

There are so many more features I've not mentioned simply because of time. I'd love to see in the comments what everyone else is looking forward to and also whether you've already been using the beta/RC versions or are going to upgrade to PHP 8 ASAP.

My year in dev

Dan Silcox — Fri, 13 Dec 2019 15:08:54 +0000

I came across this awesome tool on this post and thought it would be nice to share my stats :)

My year on dev.to

Why not have a go yourself!

PHP - 'dump' those debug statements!

Dan Silcox — Mon, 25 Nov 2019 15:59:03 +0000

Intro

We have all been there - for whatever reason your debugger is not working (or you're being lazy) so you decide to use var_dump('here');exit; or something similar during development to work out what is going on with your code.

You finally fix the issue, commit your code and push it up and then the code reviewer fails it because of your var_dump() being left in. Or worse - they miss it and suddenly strange messages (like "got here") start appearing on your test environment!

Then, having already wasted the time of your code reviewer and potentially other colleagues, you have to waste your own time and energy removing it and updating your PR. If only there was something you could do to prevent this...

Good news, there is!

Don't use var_dump!

The best thing you can do is avoid using var_dump() at all. If you're using TDD and/or BDD you likely will very rarely need any sort of debugging. In any case you should get your debugger working just in case. But this is beyond the scope of this article...

Let your IDE spot your var_dump for you

If you're a PHP developer, you may well using PHPStorm or another Jetbrains IDE - so get the PHP Inspections plugin and you will make your life waaay easier! It also has an inspection built in that underlines any var_dump() calls in red and gives you a nice warning message.

Add a pre-commit hook to save you from yourself

What's a git hook?

The concept of git hooks is explained elsewhere but basically it's an event-based script runner. So you can tell git to run a particular shell script when a particular thing happens.

The code

In this case "pre-commit" means "before a commit is saved" and the script that can be run is one that I use for my PHP projects. The part of code in particular that checks for var_dump()s is:

# Prevent committing of "var_dump"s in code
VAR=$(git diff --cached | grep -w "var_dump")
if [ ! -z "$VAR" ]; then
  echo "Detected a var_dump in one of your files. Aborting commit"
  echo "$VAR"
  exit 1
fi

You can download the full pre-commit hook from GitHub.

'Hooking' it up...

By default, git hooks are run from inside the .git/hooks directory - but you can't actually commit them to your repository from there. This is why I prefer to add them in a custom folder and tell Git where they live...

To add this (or any other hook) to your repository, you need to add the file itself and ensure it's executable, then tell git about the file (where it exists, and that it should run it):

Create a folder inside your git repository called bin/git-hooks (or whatever you want to call it).
Add your file to that folder (named pre-commit - no extension)
Ensure your file is in executable mode (run chmod +x on your file)
Edit your git repository's configuration file: git config -e
Set core.hooksPath to ./bin/git-hooks/ - like the following (there may be other keys/values in there of course...)

[core]
    hooksPath = ./bin/git-hooks/

That's about it!

What about you? Got some other really cool git hooks you're using? Why not share them in the comments!

8 tips for breaking down language barriers

Dan Silcox — Wed, 23 Oct 2019 21:18:52 +0000

This simple guide is designed to help those for whom English is a first language to communicate clearly and inclusively with those who have learned it as an additional language.

It is not intended to be patronising or demeaning - quite the opposite in fact, I have a huge level of respect for multi lingual people - in terms of human languages (as opposed to programming languages!) I only speak English, apart from a little bit of French from school, so big thumbs up to all you multi-linguists!

It is intended to help us single-linguists to avoid getting carried away and unintentionally excluding those who might find English less familiar and therefore not as easy to follow.

1) Keep to short sentences where possible
2) Speak more slowly and clearly than you normally would - don’t mumble or rush words, pronounce consonants clearly (avoid ‘glottal stops’ for example - skip to about 1 min)
3) Avoid slang/expressions/idioms - or be ready to explain them and laugh with your colleagues about how crazy they sound when you really think about them!
4) In technical topics, using well known terms, such as design patterns, as opposed to your own custom names for things, can help your colleagues as they quite likely learnt at least some of this in English (see the comments on this article for anecdotal evidence)
5) Use non verbal communication to supplement your words where possible - hands, facial expressions, tone, etc - but not excessively to the point of embarrassingly waving your arms around!
6) Listen carefully to your colleagues when they speak to you
7) Respect each other’s time zones! Don’t book all your conference calls/ meetings during their lunch break (food is a priority in any language!!)
8) DO NOT correct or patronise them!

Over to you: multi-linguists, can you think of any other points that might help you to feel more included in English discussions on technical topics? English-as-first-language-ists - any other tips you can add from experience?

Let’s all help each other to break down those barriers that exist in tech at the human level, which tech has solved in a practical sense!

Making positive decisions

Dan Silcox — Mon, 30 Sep 2019 15:27:47 +0000

Do you ever suffer from Analysis Paralysis? Whether it's on big life decisions like whether to take a particular job, or on the smaller things like what to have for dinner, it can be really frustrating to yourself and to others dependent on your decision when you are seemingly stuck in this loop:

"If I do X then A B C could happen, but wait... if I do Y then D E F could happen which is just as bad... So I should do X... but wait then A B C could happen..." (...forever...)

A friend once described the solution to this with the following analogy which I'm going to shamelessly copy:

It's easier to steer a moving car

I really like this analogy because it's so true - have you ever tried to 'dry-steer' your car? It's way more difficult to turn those wheels, and damaging to the tyres potentially, compared with just heading in a direction and adjusting course on the way.

Once you make a decision to move forward, it's inherently a positive decision - you are moving forward! You're not going backwards or standing still - and you will either win (i.e. you made the 'right' decision) or you will learn from whatever decision you took. But at least you made a decision!

Now don't get me wrong - analysis itself is actually a good thing - jumping head first into a decision (big ones at least) can be catastrophic without knowing the context, the facts surrounding the decision, the impacts of your choice on your life and others' lives, etc. I'm by no means saying skip that step. I'm simply saying that once you've scoped out the impact of, say two options that are more or less equally weighted, that is - two options that are basically both OK, but neither is perfect or an out-and-out choice, just pick one.

Most of the time, you can change your mind later anyway.

Have confidence in your own decision making - for sure, do your analysis - don't go in blind. But once you've got some basis for a decision, just make one!

One practical tip that I've learnt is to use 'pseudo-chance' to help others make these kinds of decisions:

Assign 'heads' to one decision and 'tails' to the other, and flip a coin
When they see what the coin is telling them to do, if they're subconsciously leaning in the same direction as the coin, or genuinely have no particular preference either way, they will just go with it
If however they are subconsciously leaning in the opposite direction, this will likely become clear and they'll deviate from the coin's 'decision'

Can you relate to this? Or do you have any other tips to help those who can? Why not provide them in the comments below?

The joys and perils of working remotely

Dan Silcox — Wed, 11 Sep 2019 09:42:38 +0000

For the past two years or so, I have been a part of a team spread across three timezones, representing at least eight different cultures. In one sense this sounds like a disaster already! However, we have made it work remarkably well and I feel like it has been a great success - though not without its challenges.

In this post, I want to talk through some of the successes and struggles, reflecting on what went well and what could have been done better, in the hopes that others will be able to celebrate the joys with me and learn from the perils in order to avoid facing them first-hand. So, without further ado, here we go!

Joys

Despite the distance, we really do gel as a team and have a real laugh - I have definitely made some life-long friends through the experience
We work well together and are able to ship great software
We learn a lot from each other, in terms of technology and in terms of culture, personality, etc
Personally, I am often way more productive from home - without the distractions of an open plan office
No commuting!

Perils

Communication is just never as good when it's not face to face - instant chat and even video calling are great tools, but are only ever going to be "next-best-things" to good old fashioned talking to each other face to face
Colleagues being "away" on chat when you are desperate for help is really frustrating!
Feeling disconnected from the office goings-on, whether it’s work things or the ‘watercooler’ chat!
Not being able to get hold of anyone - for example if they’re all in a location-based meeting and unavailable on chat...
Things like VPN issues can be absolutely disastrous for productivity, especially when paired with the point above about not being able to get hold of people!

I totally understand and agree with the productivity gurus saying you should turn off all notifications and "make your apps work for you" rather than the other way around. The downside is that it can, for your remote colleagues, make it very difficult to contact you and can actually leave them feeling disconnected and under appreciated.

Overall, I would still say that remote working does work, but you and your team have to all want it to work and commit to being available, building rapport beyond boring work interactions, and ultimately treating each other as humans and as equals.

There are loads of other pros and cons that I can’t think of right now - why not suggest your own in the comments if you have similar experiences!

Do you find it difficult to unplug?

Dan Silcox — Mon, 02 Sep 2019 11:58:44 +0000

I have just come back from ten days in the lovely Mijas, Spain with family. It was amazing and really relaxing - great to get away from all the hustle and bustle of "normal" life for a bit.

However I did find that it took me a good few days to fully "unplug" from thinking about work, whether it was a coding problem at the back of my mind, worrying that I'd miss important team changes or even just miss out on the Slack banter! This also made me realise that it actually impacts my weekends sometimes, this struggle to unplug. I have always tried to live in a balanced way whereby I "work to live" rather than "live to work" (though of course both are important and I always give my best while at work).

Does anyone else have this issue? How do you minimise it and stop it from spoiling your down time?

If you were designing a programming language what would your favourite features be?

Dan Silcox — Mon, 12 Aug 2019 09:30:49 +0000

Having learnt a few different languages over the years I have a shortlist of my favourite features across different languages (note I have included a few things that are not strictly language features, but are commonly used libraries that I think are just great!) - I will list my own thoughts below, but I thought it would also be a fun question to ask the community!

So here's my list in no particular order:

What are your thoughts on these features? Would you include them if you were to write a language? What else would you add and why?

Edit: one that is really useful, some would say absolutely key, in modern web development, is native strong-typed JSON serialisation/unserialisation - ie being able to convert easily between object and JSON representation without having to manually map the internal fields, especially where nesting is involved. C# has a great implementation utilising generics for the "to" object type when deserialising - the equivalent serialiser is pretty good too, with easy support for custom converters for things like string representations of enums, etc