I often experience things in my daily working life that I think are interesting. A lot of these things come from working at multiple different organisations, it's only upon reflection when you see the same thing happen and how it's dealt with that you start to draw comparisons.
For that reason I am going to start a series of posts which talk about some of these things in more detail. Hopefully you are doing some, or all of these already but if you aren't then at least it will give you some ideas about things you can try.
Reduce complexity through simplification
One of the most, if not the most important skill in successful delivery of software solutions is the ability to reduce complexity through simplification. It's likely that you are already doing this, but it's worth mentioning to ensure that awareness of the fact is always on the forefront of your mind.
Anytime you are given a requirement, task, comment or anything else which requires your help to assist in its delivery, you should be asking yourself whether it has been adequately simplified. For example, if you have been asked to build a website, you could start by splitting this up into the frontend and the backend. If we focus on the backend you could have tasks which focus on data storage, authentication and authorisation, REST API creation and documentation. Data storage could be further divided into schema management and performance tuning and so forth (you should continue until it doesn't make sense to go deeper).
Whilst you would typically work on a single item at once it's not to say that you can't satisfy several tasks at the same time, but the point is that by splitting the requirements into more manageable chunks it helps ensure that people know exactly what their responsibilities are and also provides a way to help distribute the workload efficiently.
In the past when building a user interface, I worked closely with another developer whereby I would create some components and then hand them over to him to apply any theming and styling as required. We would then incrementally release these features behind feature flags and incrementally roll things out. This process was also great at teaching us collaboration skills and was a lot of fun.
To summarise this point - there is an excellent example of how we can solve some general purpose computer science problems via simplification by using a binary search. Whilst this only works on sorted data sets, you can in effect reduce the search group by 50% each time whilst you are searching for your desired element, so it saves iterating through the set in the traditional way.
Work asynchronously
If you collaborate with people who have different working patterns to you e.g. because they are based in different timezones or because you are an early bird, and they are a night owl then this is definitely something that I would recommend. In fact, even if you don't satisfy any of the aforementioned points, I implore you to give this a go.
Anytime you need to ask / reply to some questions, or talk about something complex, why not try recording your screen and narrating as you walk through the topic in question. I've seen this work really well with Figma designs, code walkthroughs, spreadsheets or even just website demos - the point is, that this works with basically anything.
Once you have recorded yourself, just upload the file to Slack or Teams and then your colleagues can pick this up at a time which is convenient for them, and also it acts as a central repository for anyone else who needs to stay in the loop. In fact most tools have this functionality built in, so you don't need to pay for an extra service.
It might take a while to get over hearing your own voice, but once you are past this, it will really help to supercharge our workflow.
Manage context switching
Have you ever had a list of tasks that need completing, and find yourself jumping from one thing to another and not really getting anything done? I think this is quite common when you have multiple conflicting priorities, often we are tempted to try a sort of scatter-gun approach at the tasks and erode them away altogether. Whilst this might work for simple tasks that don't require much cognitive load, the benefits will soon start to diminish for more complicated requirements.
As an example, perhaps you are working on a new greenfield project, setting up some business logic to handle some payment processing; but then your boss contacts you and tells you that you are needed to support on an existing project which has some issues in one of the pricing services related to multi-currency tax calculations. For reference these both have the same priority. Rather than spending an hour on each switching back and forth, the best approach would be to specifically book out time for each one.
Some logical time divisions could be either morning / afternoon sessions (say 3 hours each with a break in between), or preferably spending an entire day / series of days unbroken. Although this might not be very thrilling for a developer to have to bugfix on some existing codebase, in the long run it's likely to be more beneficial to complete the work this way than to keep switching between each item as it will help minimise cognitive load and reduce the effects of context switching.
Design multiple solutions
Whenever you have the opportunity to design a system, or even part of one, you should look at finding multiple solutions. Although this might seem counterintuitive, by spending the extra time to work out other alternatives, you actually will probably save time in the long run.
How many times have you started working on something, only to soon realise that actually you made a mistake and the solution you envisioned is fraught with issues? The likelihood is that at least some, if not all of your deliverables will experience an issue of sorts, but by having spent the time upfront to explore more solutions will put you in a better position to deal with these eventualities.
Imagine for a minute you have to collect some information from a user. You decide to explore a few options, you might decide to use a 3rd party form and then interface with the REST API's to extract the data. Another option could be to build a simple single page application in your framework of choice e.g. React and then create a couple of node REST API's to handle the submission. Even by looking at just two simple examples, you get a flavour of the amount of scope each option can introduce. Going through this process not only gives you the option to find the solution that best meets your needs within the current constraints, but it also gives you an output which you can share with key stakeholders in the business when you are making your case.
Software delivery is pretty much all about solving problems, so why not try and find multiple solutions to every problem, and then you will have more confidence in your choices. Even the most experienced people are unlikely to get it right the first time.
Adapt your workflow
Delivering work is extremely important as we all know, but have you ever taken a moment to think about how the workflow is managed? Whilst I am a big fan of agile working, I am also big on breaking out of the mould, and think this process should be adapted relative to the size and maturity of the organisation. Agile working is like a promise, and in reality all promises get broken eventually.
For example, I found that whilst working in an early stage startup with a small highly cohesive team, it is perfectly fine to forgo a lot of the more rigid structure of an agile framework. The best example I have relating to this, is when we decided to remove Trello from our workflow. It was just becoming too much of a burden to keep and manage and was slowing down our delivery.
After our daily stand-ups, I would write a list of bullet points into Slack and then just work through these items every day, providing feedback as I progressed. Although this likely wouldn't work with larger more mature organisations, it worked perfectly for us. There was one single place (the tech channel) with all the latest info. There was no need to trawl around for ages on a backlog, everything of relevance was just there, ready to be consumed by whoever needed it.
Fail fast
This is a piece of advice which can often apply to all walks of life. For whatever reason, as humans, we struggle to let go of things. The sunk cost fallacy sums this up excellently as it depicts how we continue to progress with something because well, we have invested so much already and can't face the loss.
The best advice is simple, if something is not working, you need to ask yourself whether this is worth continuing. It doesn't matter if you have spent 2 days trying to get your hack into production, even though it was supposed to be the quickest solution when you sold it to your product manager at the start of the week. Maybe now it's time to abort and do it the correct way which arguably would've taken longer, but at least it would likely be complete by now?
At the end of the day, we are all only human, so you are forgiven for thinking that this is something you have full control over, because you are fighting your brain conditioning.
Use this link if you are looking for part two.