Managers of growing software development teams have to deal with rapidly increasing workload. At some point, they don’t have enough time in their day to look into each and every issue. If they keep doing so, they become a bottleneck in decision making, slow their team down, and put its success at risk.
This behaviour is frequent among first-time managers, especially those who have been promoted to this role thanks to being strong individual contributors. They keep relying on their old strengths which no longer serve them well in the new role.
What they should be doing instead, is to start delegating their leadership responsibilities to their team members as early as possible to get enough time to focus on critical issues, speed up decision making in their team, and increase its capacity by developing future leaders — technical leads and people managers — among their direct reports. …
Meetings, communications, and urgent requests are well known productivity detractors for software engineering teams. In this article I’d like to share how my team maintains high productivity by carefully designing the team meeting schedule, optimising team communications, and taking distractions under control to maximise uninterrupted time that each developer and designer can spend on actually doing their job.
First of all, I should tell you a bit about my team so you could get an idea how similar or different it is from yours. My team is building and maintaining the online and mobile banking apps for one of the Australian banks. We are an integrated team of software engineers and designers and we closely collaborate with several teams and stakeholders at the bank: Product, BA, Testing, and other engineering teams. We work in two-week sprints. …
This post is about my favourite approach for sprint planning for a small software development team. It is simple, quick, and pragmatic. I’ve seen it working successfully in several teams.
With this approach planning for a two-week sprint usually takes less than an hour for a team of ten people. The approach is easy to understand for new team members at their first sprint planning meeting. It is also easy to pick up for teams that only just started working in sprints.
In this article, I’ll demonstrate this approach on a 1-week sprint for a small software development team as an example. However, the approach works equally well for a wider product development team including designers, product managers, analysts, testers, support, etc. …
To get fully productive at a new job, a software developer needs to:
In our team we started to help our new hires to get up to speed sooner with a personalised onboarding process. It has been working well for us: our new colleagues have been learning quickly, contributing efficiently, and integrating into the team well.
In this article I’d like to share the details of our approach. Its key parts are:
From a software engineering perspective the product life cycle can be split into six stages: Development, Introduction, Growth, Maturity, Decline, and Abandonment. Each stage has different goals and challenges, so engineering managers have to shift their focus accordingly to keep providing best results for their organisation:
A coding test is a crucial part of the interview process for a Software Developer role. A take-home coding test combined with a follow-up interview can tell interviewers a lot about the candidate’s prior experience and potential performance at the new job. It is also a great opportunity for candidates to demonstrate their skills.
Let’s take a look at a few recommendations for software developers on how they can approach a coding test to increase their chance of passing it successfully and getting a job.
Start with carefully reading the coding test instructions and understanding what is required from you. …
Aspiring startup founders often think of building a web or a mobile app. However, launching such products requires lots of efforts and collaboration from people with various skill sets: engineering, infrastructure, design, PR, marketing, sales, product management, support, analytics, industry expertise, etc. If you are bootstrapping, it is not easy to find co-founders with required skills. If you are working with investors — finding talent is still time-consuming and expensive.
Unlike web and mobile apps, API products require less effort to build, launch, and maintain. APIs have well-defined use cases, so less customer support is required. API products don’t need complicated UIs, so don’t require much design and front-end development. API customers are technical and curious people, so marketing and PR efforts can be more focused, efficient, and less costly. …
REST APIs are probably the simplest way to integrate two applications over the Internet. Most web developers have integrated with or built them.
I’ve written this guide to help developers design and build REST APIs that are easier to integrate with and easier to maintain. It includes tricks that I’ve borrowed from my colleagues, ideas that I learnt from books and articles, and some things from my own experience with REST APIs. So, you may find these best practices a bit opinionated.
This guide starts with REST resources, then looks into requests and responses, then versioning, security, and, finally, developer experience. …
Your first job as a Software Developer can be the start of a great journey. It can also be a stressful time because of all the new people, new culture, and your new responsibilities. Few fresh starters know how to integrate into their first team and not every manager is able to offer them enough support.
I’d like to share some advice on how software engineers can integrate into their first team sooner, become valuable contributors, and avoid isolation, conflicts and unnecessary stress along the way.
Here is a quick summary:
When building a new software product, it is crucial to pick the optimal architecture as early as possible. The right architecture supports the engineering team in building the product. Poor architecture choices hinder development and may lead to expensive rework in the future.
In this article I’d like to share an approach to designing a future-proof software architecture that has helped me to come up with simpler designs, ship new functionality faster, and avoid big architecture changes as the products evolved.
What I particularly like about that approach is that it scales up and down depending on the project size (product, service, or just a large feature), and that it can be as rigorous or as informal as appropriate for the engineering culture in an organisation. …