How to be better at teamwork and communication in software dev? [closed]

Question

Basically, what resources and books to learn this better for engineering?

I'm used to working as an independent consultant in programming and the few teams I've been on skewed heavily dysfunctional(long story). My latest role pulled me aside to say my work is great but my lack of communication on progress, updates, code changes etc. Are causing issues with during production releases. They want more sign off before I push major or minor changes and more transparency so it doesn't happen again.

Any advice or resources other than "talk more to my boss more often"?

Answer 1

It sounds like you have a process problem as well as a communications problem - for one thing, you really should not be updating the software you have in production without anyone else know what you have changed and will be updating.

There are several things that can help here. Apologies if you've got or have done these already:

Version control software

This tool is ready made for communicating code changes as it records those changes as they're made. Got is the most popular these days - you can use GitHub (private repositories are allowed) or there others like GitLab which you can even run internally. These come with additional communications channels where code changes can be discussed before merging.

Peer programming

This is good for two reasons - two people will learn from each other, and two people will see a problem from slightly different angles. In the long run, this leads to better code and knowledge transfer in the team.

Code reviews

Stuff should not be pushed into master or out to production without being reviewed by a peer. This gives some of the advantages of peer programming - having a second pair of eyes go over code, looking for edge cases and side effects, can drastically reduce the number of bugs introduced into production.

One thing to remember - the output of a peer programming session should still be reviewed by a third team member.

Get a testing environment

We have a sequence at our place:

1. Development
2. Build
3. Review (deployment test)
4. Production

Changes don't get into build until there has been a code review. Changes don't get into review until the build has been checked by the Product Owner. Changes don't get into production until QA approves the review.

This may be a bit overkill for small organisations, but you should have at least one layer between development and production.

In fact, at one early point in development we had another phase between build and review called staging - as the development stabilised we were able to remove this step.

Issue tracking software

We use Jira - there are many others.

Again, it allows discussions of issues (before or after making code changes) and you can set up workflow to integrate with version control, or to simply assist in tracking.

Bugs and features are described, discussed, and tracked through creation, development, testing and release. Estimates on effort (or time) can be made to help with project planning.

Daily standups

Even if you are not doing agile style project management, these can still be useful within a development team.

These meetings are designed to be quick. Even in a large team this doesn't need to take long. I've heard of 20 man teams getting their standups done in 10 minutes.

Each developer answers three (unspoken) questions:

• What did I complete yesterday?
• What will I complete today?
• What obstacle is blocking my progress?

Save discussion and advice until after the stand up and let people get back to work quickly.

Keep a diary

Get a notebook and keep a very succinct diary. What you're working on, what problems you had, what solutions you tried/succeeded with. It doesn't need to be massively detailed (details belong in code and documentation), but it will help with the stand ups or just when your boss asks for some progress report.