This content is available as a Youtube video on DeveloperHabits YT channel. If you're interested in topics such as growth mindset, developer lifestyle and (web-related) technical tutorials, feel free to check it out and subscribe!
Two weeks ago I finished a project that taught me a lot about mentoring, leadership and myself. Shortly put, I had the privilege of leading a project of 5 developers(myself included). As it was my first time doing something like that, I thought it'd be nice to share my key takeaways from that experience.
1. It all starts with requirements
You can't start building if you don't know what to build. So the first thing you should do is talk to the stakeholders. Let them describe what they need. Try to understand each detail of their requirements.
That said, keep a critical mind towards the requirements. As it's easy to get carried away with "nice-to-have" features, question what value does each requirement bring? Are they actually necessary or can they be dropped? Be a supportive, but a critical partner to your stakeholders.
2. Plan the technical part
Some people like to start building things right away. I've tried that and failed, multiple times. That's why I believe It's necessary to plan and research.
After gathering the requirements, planning the technical part should follow.
Come up with an initial architecture and tech stack. Compare different solutions, try to find cons and pros for each one of them. Talk to your colleagues.
If there are any unknowns in the stack, validate them by building an MVP. It will save you tons of headache in the future.
Remember, by having good research and planning, you bring down the likelihood of having problems in the future.
3. What you've prepared is not set in stone
I'm a fan of agile development. And one of the best things about agile development is that it's open to changes. Inspired by that, I advise you to use all your research and planning as a guideline, not as something that's set in stone. The truth is that problems may still pop up and you may need to come up with a new plan. It's ok.
For example, in my latest project, I planned to use Kafka for sharing data between various data-centres. During the project, we decided that for the first version, there's no need to complicate things by having information stored in different data-centres. A big decision that had a huge impact on the architecture, but at the moment I'd say a valid one.
4. Make sure everybody understands the plan
It's important to take time, especially in the beginning, to make sure each member of the team knows what you're going to build, how you're going to build it and WHY you're going to build it that way.
It's important for various reason. For example:
- team members understand why each task is needed
- they can provide ideas for improvements
- when you're away, people know how to move forward
- but most importantly, during the project, everyone can see what's the progress of the project and see what's waiting ahead
5. Minimise the dependency on others
In order to save time and have a nice workflow, try to minimise all the dependencies on others. Or at least, start working on them at the very beginning of the project.
For example, if you need a design for the project, let the designers provide you with their work before you go on a project. And make sure to check if everything's clear to you as a developer and a project lead.
You'll thank me later because, during the project, you want to move fast and waiting for others is just a cause of unnecessary stress.
6. Make an extra effort for chunking the tasks
About creating tasks...Break them into small chunks and ideally provide a how-to or suggestions for solutions. It makes it easier to build, test and review the tasks but also provides a great sense of accomplishment.
Oh and...you don't need to create tasks alone. Have a weekly-planning meeting for example, where various assignments are discussed and broken into tasks. It also helps people to sync up and ask questions about what's coming.
7. Always be at least one step ahead
As a project lead, you must always have the bigger picture in front of you. When team members or stakeholders want to know what's coming next, you should be the one to know the answer.
Tech-wise, you must know how various parts connect together. When people ask you about the connection between various tasks, you must be able to explain them.
My advice here is to start the week with an early morning and go over the upcoming week and the whole project.
8. Keep the meetings to the point
Meetings...I'm not a fan of them because it takes time away from all the participants. That said, they are necessary. That's why it's vital to make them as efficient as possible.
My advice? Make sure that with every meeting you have an agenda and a list of expected results. Share them with participants beforehand so they could prepare. When discussions go off-topic, bring people back to the main topic. Oh and...follow the clock.
9. Team culture is important and you've got a role to play
One thing I had not thought about before but learned during the project is the importance of creating a team culture. It's easy to take it for granted when you are building projects with team-mates you've known for a while and get along with well. But in my case, many in the team didn't know each other before. To fix that, one of my team-mates nudged us to have various team-events and team lunches.
Also, during the breaks, try not to talk just about the work stuff. That can be done...during work. When you're at lunch, try to get to know the people, how they're doing etc...It can lead to many great initiatives and makes working together so much better.
10. Have 1:1s
I'm a huge fan of 1:1s. Your team members have their thoughts and ideas for improvements and 1:1s are a great way to hear them out.
That's the place to discuss various technical and non-technical topics and find solutions to problems. It's also the place where you as a project lead can hear them on topics that are not to be discussed publicly.
By having 1:1s with all of your team-mates, you'll have a whole picture of how everyone's doing, what they're ambitions are but also provide advice and guidance.
11. Delegate and trust others
One person can't know everything and do everything. That's why I advice you to delegate as much as possible.
When there are business questions and you have a separate product manager, let him/her handle all of the business questions.
Tech-wise, I found it useful to distribute focus. I set myself as the lead of back-end development and my colleague as the lead of front-end development. It turned out to be a great initiative as I could put more effort into guaranteeing the functionality of back-end but also take care of the management side of things.
Based on that experience, I dare to say that sharing your responsibilities with others makes your life easier and less stressful.
12. Be the one who clears the road
During my last project, it happened quite often that there were environment issues or minor bugs that stopped others from working.
As I wanted the team to continue building the features and functionality, I took it upon myself the fix the blockers.
That way, the team could focus on what's important - delivering the project.
Good examples of such situations are tasks related to creating repositories, creating databases or setting up linters.
It's not always fun, but it makes others' lives easier.
12+1. Don't try to be the hero
There were times during the project when I forgot I'm the project lead and let the developer in me take over.
When I felt the pressure of time and we had bigger obstacles, I found that explaining everything to everyone would just lose us time, so I decided to solve them by myself.
In the end, I got things done, but building the solution in most cases took longer than expected and it was hard for others to provide help when needed. But even more importantly - as I got swollen into coding the solutions, my quality of preparing for meetings and creating tasks went down, which made other teammates also suffer.
That's why I advice you to always let the team know what's going on and break challenges into smaller chunks.
The points mentioned above can also be seen in the DeveloperHabits video. To be honest, it was really hard to gather all the ideas and prioritise them so I'll just write down all the thoughts I had that were not mentioned in the Youtube video.
Listen to others first. Present your ideas in the end...
Listening... I can't overemphasise the importance of that skill. People are different - some like to say out loud their opinions, some need encouragement. That's why I've found that letting others talk first is better. You get to know their ideas and in the end, when there's a chance, you can also address people who haven't said a word.
Lose the "We'll do it later" attitude. You probably won't.
If you're a developer, you should know that lines preceded by a TODO comment, usually don't get done.
That's why I advice you to do things properly from the very first time. They don't have to be perfect but they have to be in a state where you can come back to and be content with what you see.
For example, when setting up a new project, take the extra hour or two to set up linters, testing environments, coding conventions etc.
It will save you refactoring time in the future.
Think how to test things.
I've been in projects where we unit-tested stuff for 100% coverage just for the sake of it...In the end, the tests were really hard to follow and when code changes were made, it took lots of effort to also change the tests.
I've also been part of projects where we don't cover everything 100%, but the tests are efficient and easy to follow.
My advice - test what's important. Test the most critical parts first and if you have time, go over the edge cases. In my latest project, we thought about unit-testing our main functionality, but in the end, understood there's not much time. Instead, we wrote functional tests that covered the main business logic. And it has already caught bugs before going live.
Use pair-programming as a way to share knowledge
Pair-programming...I should make a separate video on that. Very simply put, pair-programming is a method where two developers solve the same problem together.
I find it to be really useful when solving complex problems, as it's really easy to get stuck with them when you're alone. With pair-programming, you can always discuss and validate the solutions. And it's also a great way to learn from others.
Underpromise, overdeliver
Something I've already learned during freelancing - promise less, deliver more.
Imagine you promise to go out with your friends but in the end, decide not to go. Obviously, your friends will be disappointed. Whereas, if you tell them you're not coming early on but later show up, they'll be pleasantly surprised.
That's how I also approached stakeholders for our project - they asked if we can deliver X, Y and Z features, I told them no. But we kept those features in the backlog and one of the three features was actually delivered. They didn't expect it and were pleasantly surprised.
Top comments (0)