I want to start this thread apologize for my bad English. I'm from Brazil and I'm not used to writing in English since I lived in USA for 4 months in 2016. I came to this community from a the "4 things i learned after getting users" post and thought that was a really good piece, thanks for the tips.

I'm in the second year of a Software Engineering Graduation and thinking about recruiting some colleagues to start some side projects. The objective is to search in our circles for business that could really get some advantage with a simple website. But since we don't have any experience beside the university I came here for some tips to deal with the other developers. I think that how I will interact with the clients is already solved but I'm afraid of how difficult can be dealing with others devs. Anyone here have any tip?

hey @DanielLeao and welcome to the site! thanks for the kind words about the blog post.

i've actually never worked freelance, myself. But i will say that working as part of a team gets easier the more you do it - I think your case is a little different that that of working on a team within a company, since i'm assuming you'd be tackling smaller projects, which would call for less people working on the same thing. Perhaps it makes sense to try and find collegues who compliment your strengths. For example, if you find yourself really good with Web development, find someone who likes to stick more towards either the design or back-end side of things. Or if you have multiple front-end developers, find pieces of a project that can be built in isolation.

maybe if you find yourself working with different clients in similar industries, work on creating a framework from which to start building from, so you aren't starting from scratch each time.

for what it's worth though, i think a lot of small business would benefit from using services like Wordpress or Squarespace or one of those CMS. I think you'll find that's the easiest approach, since you don't have to maintain any servers and you can just worry about delivering a solid Website for these businesses you might be targeting. and because of that, having many people coding one project might be tough.

First: @orchids there is suport for some kind of <span> to make the quoting smaller? Maybe it would be a nice add?

Thanks for the tips, we pretend to be working in teams of 2 with plus one manager. And I really since we are doing a first website of the "Company" the idea of build that with a similar approach on the functionalities and design that our client from a close industrie as digital marketing (We already have 2 possible clients in the space) to use as a base or "framework" of these projects.

And to explain more of the project for those who will respond later:

• It will be only front-end with HTML, CSS and Javascript (I personally already know a bit of the backend but me teammates are not ready and I don't want to do large update and need to worry about the project running with details)

• Teams of 2 + 1 manager (who probably will code)

• I will manage in Notion since I have a little bit experience and maybe post something about it here in the future

• Design in Figma (I think this will be the most challenging task for everyone)

First off, don't worry at all about your English; you're doing great and you really don't need to preface your post with any apologies.

In terms of working with a team, I would just point out a few observations that I've made or become aware of:

Harmony is valuable

A shared understanding and a agreement around how to do something is oftentimes more valuable than the absolute perfect solution. An example of this is an auto-formatter: Oftentimes it's better to have one exact formatting style even though it's literally no ones favorite style in the team. The fact that there is no ongoing conversation or adjusting going on in PRs is more valuable than any one person getting "their style" written.

A programming language that is not optimal for what you are doing or is considered "worse" than another can also be exactly the right tool because the team understands it and has an intuition for how to solve problems in it.

This also connects to what @orchids said about framework to some degree; if you can find a shared understanding about how to do things this can either be used via already existing patterns and frameworks or you can find ones that exist in your specific group.

Happy people work better

If someone wants to do something and is excited about it, it's often more valuable for them to do that instead of what would be highest up on the priority list in a more absolute sense. They will feel like they have more agency (control and oversight over what they put their energy into) and thus motivation. This increases overall productivity.

The other side of this is that lack of agency is a key component in burnout and overall demotivation and can have much, much bigger consequences than not working on the absolute number one priority on the list right now.

Be charitable in your interpretation, be strict with your own communication

Assume the best in what people are communicating to you and be strict about what you communicate to others. This includes what context you believe people have when you communicate with them. An example of this is that perhaps you have used several databases and have some intuition for what that means, but this may not apply to your group of peers. Yes, sometimes this means someone doesn't know something that you might think they should. Adapt your communication to the receiver in general. Don't assume there is an overall acceptable way that works for everyone as you might find that having a purist "one true way" that seems like it should work still gets you into bad vibes with people.

It's much better to ask than to be worried about not knowing

I've been programming since 2000 and I have basically no shame about asking what something is, how it's used or really anything in the work process. Very rarely is the problem you when it comes to not knowing things. We work in a vast field and there is too much to know. On top of that people make up new vague terms and acronyms every year; it's absolutely pointless to know all of them beforehand.

Don't assign or take on blame

When something goes wrong, it's important to not try to blame anyone. Blaming things is fine, as long as you can actually point to them being a key part in an error being made. If someone deletes the prod database that might seem like a perfectly fine situation to blame them, but in reality the lack of safeguards in that scenario was an integral part in that mistake being made.

Additionally, never take on blame, but take responsibility for improving yourself and the circumstances around mistakes. It can seem fine to take blame for things but the key here is that blame is not about solving things, it's about assigning shame. This is a very bad motivator and though you might feel like you can take it, you're much more likely to turn those feelings into resentment over time.

Planning is useful, plans less so

Planning how something should go (a roadmap, a feature, etc.) is a lot more useful than the resulting plan is. Planning together when everyone is bought in creates the shared understanding you want and can build teamwork and team spirit. The plan you end up with should be considered subject to change and not necessarily valuable in itself. It should always be subject to change.

A part of business that is interesting is how they aim to fulfill the needs and solve the problems of people. I think that maybe if you aim to solve someones issue, or fulfill their needs, you might be able to progress in a direction.