Organizing your programming

[MamaSpoldi]

Originally Posted by SamcFuchs

What if you're not there? As a lead programmer, I would want more security, so that if the mentor was missing or busy, I would still have control. I don't know how many programmers you have, but this system doesn't seem very scalable - I would be concerned about kinks in collaboration.

First, I'm always there... just ask our programmers.
Also because of our development methodology there is somewhat less interaction between the coding being done by individual programmers than for some other teams. In general, no 2 students are working on the same source files. Each programmer works on a class that is related to their own robot mechanism. The exceptions to this are related to button assignments (and their implementation in the main code loop) and the autonomous mode coding which are generally handled by the lead programmer. Although the autonomous code generally resides in the main robot class it is isolated in separate function which is simple to merge with other changes if needed.

Originally Posted by SamcFuchs

I like that I don't need an internet connection to git commit. And besides, if you need a mentor, how can you deploy in queue? /s

We never deploy in queue. That is a very dangerous idea... mistakes happen when you are rushing. We always do a basic system test after deploying code to verify the robot operates correctly.

Originally Posted by SamcFuchs

I guess this works if you don't make too many changes at competitions. Personally, I've been known to make anywhere between 10 and 20 revisions at competitions, with I think a high of 30. Those would be very specific file names.

We generally have more changes at early competitions than at later ones. Even so, the naming-system we use gives us 26 revs per day of competition which seems more than sufficient even based on your estimate.

Originally Posted by SamcFuchs

So after all the work at a competition, you have to summarize that all into one revision?

Each deployed version can be checked in separately, and in fact that is often done for early competitions when there are more changes made. We mark the final versions of each file as a tagged revision, ie. this is the code from event X.

Originally Posted by SamcFuchs

Personally, I will promote git and GitHub for as long as they are the status quo of the professional programming world. I think it's important to learn those skills if you want to succeed in the workforce, and learning new skills that are applicable to the real world is what FIRST is all about.

I strongly agree that the goal of FIRST is providing skills that will help students in the real world. But I think that you may be overestimating the universality of Git. I realize that it is a big part of the online, shareware community and it is great that it is being used by FIRST teams as well. But I have been a software engineer for over 30 years and have only seen it used on one commercial project that I have been part of. I do not want to imply that it is not used commercially but to point out the commercial world is vast and does not always reflect what you see/hear on the net.

Originally Posted by SamcFuchs

I'm curious, what don't you like about git?

I don't care for the paradigm used by Git and some other recently developed source code control systems. Like I said, maybe I'm a bit old fashioned. I prefer the straight forward use of check-in and check-out (or commit and update if you will) rather than commit/update/push/pull. I just find it unnecessarily complicated and redundant. Of course, I'm not a big fan of the cloud either... I don't trust it yet.

Originally Posted by SamcFuchs

By the way, thanks for your help at Waterbury. Thanks in part to your help that day, 236 went 11/11 successful autos at CMP. I'm working on motion profiling and vision for the offseason, and maybe we'll something new next year to show off. Hope to see you at CT state champs!

Always happy to help a fellow programmer. See you Saturday!