Hey, I'm currently in college, and we were tasked to work as a group to build an application of our choice.
I'm currently the leader of our group and I'm disappointed in myself for my incompetence, because running the group has been hard and disorganized.
What standards/guides/resources do you setup or prepare before jumping into the actual building of the project (coding)?
How can I make sure that boundaries and expectations are set?
How do I make our collaboration smoother and clearer?
Thank you!
Top comments (17)
The first thing you should do is establish practices that the group likes. How you name your variables, how you organize your code, how you style it, how you split the files, essentialy everything regarding "writing code" and its conventions. Find the common ground the team agrees upon so that everyone is on the same page and you all follow the same patterns when writing code. This alone will help tremendously.
I would like to add something in the term of collaboration smoother to your good advices.
Since your group will build an application, I suggesst you make use of any version control as your convincene. I would recommded you use Git with any git provider like Github, Bitbucket.
In the Git version control there will be useful feature like code review, pull request, branching, etc.
Good luck
We use git and Github right now, but still, thank you!
Great advice!
Additionally, I like to automate checks enforcing the desired style.
This can be accomplished by using tools like Prettier.
I'll work on this, thank you!
We have good experiences with paper prototyping when requirements are unclear and the team is still fresh. People can get to know each other, rules can be settled, first design ideas can be put into the product/service and stakes are low so there is also low stress and high creativity. In that phase you can already learn the characters of the people and take this into account when later stakes become high and coding starts to get serious.
Will definitely remember this and be more aware of how I can lead different characters. Thanks 💯
I think collaboration expectations come first — code reviews, etc. Since the project really will have a clear beginning and end (as far as we know, right?) make sure everyone knows that you're not going to approach this the same way Microsoft would.
With code, set some standards and patterns you know you have a good idea about, but let everybody know it's normal that you can't figure out everything upfront. You'll need to figure out what works for you as you go. Setting up a time to touch base on patterns that are and aren't working on a regular cadence will help.
Good luck! I guarantee you're doing better than you realize. The truly disorganized process wouldn't even be lead by someone thinking about these things at all.
Hey, thanks for the thoughtful and helpful reply! I've setup a meeting with the group to touch base. Here's a unicorn for you 🦄
It might seem silly, but I really like seeing if the team is up to having a team name and theme. The team theme is surprisingly useful when writing test code, because instead of boring personas like
personAandpersonB, you can write code for, say,marioandpeachinstead. Really helps with creating a sense of identity and injecting a little bit of fun.Sounds like something I would honestly do to keep things light and interesting!
Thanks for sharing!
If there is an existing style guide or set of conventions someone else has established in the tech you're working with, you may consider using that as the basis for your approach. That might make the team more bought in and help you make decisions.
But make sure to set expectations that it's not sacred and you may need to break patterns pragmatically.
Great advice! Thanks 💯
Naming convention, programming paradigms (functional, object, or procedural), software design patterns, simple coding rules and realistic deadlines plays a lot in gettting things done in programming and software development. A programming project is not necessarily to challenge, (as some programmers like I was did think)) but to allow to explore your inner posssibility of problem solving techniques and purpose-driven solution within laid-out schedule, resources and the team available.
I can definitely quote this to motivate them to tackle challenges. I appreciate this 🦄
Group projects are hard, especially if you're dealing with similar levels of experience and are "bootstrapping" a team. The most important aspect of any project is shared vision. Does everyone know where you're going?
To do that, talk about your application. Write it down. Say what it is. And more importantly say what it isn't. This is about establishing the boundaries of what you are going to work on.
You also want to get a sense of what others experiences are regarding collaborative development. Have folks worked in version control? If so, what did that look like? What tools do folks use? Have folks used style guides and linters to provide guidance? What's worked for them? What do they recommend? (Leaders ask lots of questions and let the teams solve the problems that the team is experiencing)
For your language(s), do folks have references to best practices? These can quickly overwhelm, so really narrow it down. If I had to pick 1 strategy from all best practices, it would be "All methods must be less than 10 lines long". (I've since lost the study, but this leads to many of the positive strategies for coding)
As you move into coding, when folks contribute code have them explain how this work completes a portion of the project. Stating what done looks like is a very powerful strategy in software development; share it and have conversations about it.
Leave space for folks to say "this is done because I completed these functions and wrote todo items for these other functions." The goal is to move forward with shared understanding.
Love how well thought out this is! After reading through the comments before I scheduled a meeting with the team and I realized that having clarity really brought the team together.
It was like day and night. Thank you for this!