DEV Community

Kristian Quirapas
Kristian Quirapas

Posted on

What standards, guides, etc. do you settle before starting to build a project with a small team?

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!

Oldest comments (17)

Collapse
 
ben profile image
Ben Halpern

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.

lie detector meme

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.

Collapse
 
kquirapas profile image
Kristian Quirapas

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 πŸ¦„

Collapse
 
sherrydays profile image
Sherry Day

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.

Collapse
 
kquirapas profile image
Kristian Quirapas

Great advice! Thanks πŸ’―

Collapse
 
jankapunkt profile image
Jan KΓΌster

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.

Collapse
 
kquirapas profile image
Kristian Quirapas

Will definitely remember this and be more aware of how I can lead different characters. Thanks πŸ’―

Collapse
 
sgoulas profile image
sgoulas

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.

Collapse
 
kquirapas profile image
Kristian Quirapas

I'll work on this, thank you!

Collapse
 
tobhai profile image
Tobias Haindl

Great advice!
Additionally, I like to automate checks enforcing the desired style.
This can be accomplished by using tools like Prettier.

Collapse
 
lengsovandara profile image
Sovandara LENG

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

Collapse
 
kquirapas profile image
Kristian Quirapas

We use git and Github right now, but still, thank you!

Collapse
 
mrpaulishaili profile image
Paul C. Ishaili

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.

Collapse
 
kquirapas profile image
Kristian Quirapas

I can definitely quote this to motivate them to tackle challenges. I appreciate this πŸ¦„

Collapse
 
auroratide profile image
Timothy Foster

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 personA and personB, you can write code for, say, mario and peach instead. Really helps with creating a sense of identity and injecting a little bit of fun.

Collapse
 
kquirapas profile image
Kristian Quirapas

Sounds like something I would honestly do to keep things light and interesting!
Thanks for sharing!

Collapse
 
jeremyf profile image
Jeremy Friesen

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.

Collapse
 
kquirapas profile image
Kristian Quirapas

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!