This is the second part in the series. If you haven't read part one, then I recommend you do that first.
Product and technology cohesion
Delivering software solutions is seldom purely a job for just engineering. Whilst developers might write the code to build the application or service, without any guidance it's difficult to deliver something of meaningful value.
In larger organisations, it's not uncommon to see product and technology as separate business functions. As an organisation scales its inevitable that layers of management and leadership are required to steer the ship, but making such a large distinction will in my experience only end to under-performing teams.
When separate, you tend to find different goals and objectives at the forefront of their priorities list. Obviously we want to empower people and teams to have as much freedom as possible in their daily working lives; but if not careful making such a big distinction can cause information silos and misalignment.
Instead, it's recommended to ensure product and tech are closely aligned, both in organisational delivery requirements and also on day-to-day tasks. Once this is ingrained into the minds of the employees it should help to minimise issues in delivery and conflicting priorities.
Stretch yourself
This is a really simple thing we should all be doing. Again, this is not limited to software engineering, but applies to all walks of life. Pushing yourself out of your comfort zone brings a sense of fulfilment and energy. If you want to keep developing you need to expose yourself to these somewhat uncomfortable situations.
If we take a real-word example for a moment, say you are a recreational runner who goes out 3 times a week on the same route and roughly the same pace, whilst that's a great start, if you don't start to increase your mileage, speed or intensity, eventually you find yourself stuck at that level and could even lose interest and stop. Conversely, if you start to slowly push yourself, when you look back at how far you come over time you will start to feel amazing, and it will give you loads of energy.
Similarly, for engineering, you should be out there asking those big questions in meetings, or putting your name forward for tasks that other people might want to take on because I guarantee you will learn a lot in the process, and hopefully an equal amount about yourself.
I recently got asked whether a less senior developer should be reviewing PR's for a more senior one. My response was simple, the answer is ‘yes', by doing so it allows you to stretch your understanding and gives you a look into the mind of a more experienced developer and hopefully help you to reach that level yourself one day.
As a final thought, have you ever been in a situation where you are dependent on another person / team's deliverable to unblock you? For whatever reason, their goals are not aligned to yours, and you are unable to proceed e.g. perhaps you rely on a bugfix for REST endpoint that is written in a language you are unfamiliar with? What is stopping you from looking at the code and trying to figure it out? Even if you can't open a PR, you might be able to provide some valuable insight and unfree yourself. Without stretching yourself, this just wouldn't be possible.
Contact with peers
If you work in a large organisation, and spend most of your time in the workplace then this may be less relevant to you, however, you shouldn't underestimate the importance of being able to interact with people external to your organisation, as they will most likely be able to add some value here. It can also help to break some effects that highly cohesive teams can face, a common example of this is Groupthink where people start to think the same thoughts and don't risk challenging the status quo for fear of ridicule.
Whilst there are many benefits to working from home, or wherever you please. Doing this for extended periods of time without much interaction with your peers can actually have detrimental effects. As human beings, we are very sociable creatures who historically lived, worked and survived together in tribes. In our more ever connected world, we actually seem to spend more time interacting with people through a screen or a microphone and speaker than we do in real life.
For that reason, I would recommend taking the time to meet up in real life with people who share the same interests as you. If you are a developer, go to a developer meetup; if you are a designer, go and find a creative meetup and so forth. By challenging yourself to go out and speak with other people, I not only guarantee you will learn something new, but it will also help to improve your confidence, self-esteem and general well-being. As an added bonus there is often food and drink provided, so if that doesn't sweeten the deal I don't know what will.
As a final note, if you are unable to meetup in person, then you could opt to attend virtual meetings which is fine of course, but it won't give you the full benefit of a face-to-face meeting and after a long hard day at work the last thing you might want to do is to spend more time on the computer.
Maximise downtime
Have you ever found yourself sitting there twiddling your thumbs whilst you're waiting for your CI pipeline builds to finish or to get enough approvals on your PR's, so you can merge your PR? Well you're probably not alone. From an external onlooker it's easy to make comments like, ‘why don't you just move onto the next task?' or ‘you spend more time sitting there than actually doing work'. But in reality often it's more difficult than that for a couple of reasons.
Often it's hard to make that mental switch from one thing to another, especially if the task has been an arduous one and has taken a lot of effort to progress to this stage. It can also be difficult to let something go when you are so close to the finish line.
In order to make the most of these 5 or 10 minute stints, I recommend you have a plan ahead of time of things onto which you could focus your attention. Whilst there are no real hard and fast rules about what could be undertaken, it's best to focus on small manageable chunks of work (preferably that can be completed in one sitting). It wouldn't be beneficial to look at something which requires a high cognitive load, and besides if that was a possibility then this section of text would be irrelevant anyway. Some examples could be:
- Replying to that email you have been saving (or even just clearing your inbox of irrelevant messages)
- Clearing messages on Slack / Teams which don't require any further action from you
- Adding an extra unit test or two to your current project or something else you know would benefit from it (this should not be an excuse for not doing testing in the first place)
- Filling in your timesheet / completing any other minor administrative tasks
- Read a technical article (just don't fall into the trap of forgetting to go back to work)
- Make some notes about how you could improve your current working process
As you can see, the options are practically endless. The key takeaway here is to ensure that you are aware of yourself and how to best use your time. You are probably doing one or more of these things, but if you aren't then it might be time to take stock and do a personal evaluation so you can improve your efficiency.
Agile in a waterfall world
As we work in our highly-cohesive cross-functional agile teams. Have you ever wondered why it always seems like other parts of the organisation are out of sync? In fact, this is not limited to just the surrounding organisation, but also spans far and wide across all the stakeholders you are likely to interact with. In short, just because you are working with a flavour of agile, it doesn't mean that everyone else is?
Take finance for example, they spend time processing payments, working on the company accounts, doing any relevant financial due diligence and then preparing to be audited. Although you might only collaborate with them on small items so might not know much about how things are. How many of these people do you think work in an agile fashion? Although I can't be certain of this, I would imagine that the percentage is much lower than those who are delivering software and other digital solutions.
Another example could be the executive team who are working hard on all manner of tasks, not least ranging from their visionary strategies, sales forecasting and even just working hard to keep the lights on or so to speak. Do you really think they prioritise their tasks into 2-week sprints with daily stand-ups and retrospectives looking at what went well and what didn't? The answer is probably no, and not that they don't do all these things as and when required, but more just because they need to keep many plates spinning at once so would likely use a less formal version of an agile workflow if they do so at all.
Whilst it might sometimes be an inconvenience for others to not be on the same page as you, it's worth being aware of this fact so that you can do your best to work around these limitations of ways of working.
Automation considerations
Have you ever completed a repetitive task several times and thought to yourself that it would be a good candidate to automate in some way? If yes, you probably had another thought about how it probably wasn't worth the time and effort required, especially when it's not something you would need to do again. Typically, you end up doing it again many more times in the future, but it's too late to automate now right?
If any of the above resonates with you, then you probably want to have a plan in place about when to automate a task or not. There is a popular comic which explores just this on xkcd, however, I think it can be even simpler than that if you follow the simple rules:
- The repetitive task needs to be done more than twice.
- It's possible to automate the task with scripting / macros or an automation tool.
If both of the aforementioned points are correct then you should in my opinion look to automate this task. Not only could you save yourself a headache down the line, but it would potentially also act as a sort of documentation for other users who are lucky enough to pick up the task in the future. The automation job could then be implemented in a playbook, CI pipeline or just run manually when criteria are met. It also has the potential to reduce any issues arising from human error (assuming it's set up correctly).
If you find a task which you are struggling to automate, perhaps because it involves multiple disparate systems without any ability to integrate with an API etc., then instead of trying to tackle the entire thing, look to see if there are any micro automations which can be done instead. Even if you have to convert from a malformed CSV into a JSON manually, at least by having that JSON object you should be able to then publish it to the next step in the process. Manual intervention is perfectly fine if it can be justified.