|
48 | 48 | </ul> |
49 | 49 | </div> |
50 | 50 | <div class="body"> |
51 | | - <h1>Software for non-software team members</h1> |
52 | | - <blockquote> |
53 | | - <i>This is an email Tyler sent in response to a verbal request for |
54 | | - feedback on formal varsity letter requirements. It is being preserved |
55 | | - here for posterity.</i> |
56 | | - </blockquote> |
57 | | - <p>Hi Grace,</p> |
58 | | - <p>Since you mentioned on Tuesday that the team was putting together more |
59 | | - formal varsity letter requirements, you may be interested in the |
60 | | - requirements the software team has been using for the last 2+ years. They |
61 | | - are linked on <a href="../">https://frc3512.github.io/admin/</a>. This |
62 | | - email was originally intended just to mention that, but the fact that |
63 | | - varsity letter requirements are even an issue implies there are more |
64 | | - systemic issues. The rest of this email elaborates on what I mean and how I |
65 | | - feel these issues should be addressed.</p> |
66 | | - <h2 id="Varsity_letter_requirements">Varsity letter requirements</h2> |
67 | | - <p>I'm hoping the software team's varsity letter requirements can be |
68 | | - incorporated into the team-wide requirements in some way. Having every |
69 | | - subteam document what constitutes a varsity letter in terms of specific |
70 | | - hard and soft skills as the software team has done would not only give new |
71 | | - students an idea of what to expect as a member of each subteam, but would |
72 | | - also help leadership develop an appreciation for the work each subteam |
73 | | - does. This would address frequent complaints of varsity letter |
74 | | - recommendations being overruled, only to have them reversed when the |
75 | | - subteam in question challenges it.</p> |
76 | | - <h2 id="Basic_knowledge">Basic knowledge</h2> |
77 | | - <p>As an example of what I mean by appreciation of each subteam's work, the |
78 | | - leadership (at minimum) should be able to understand at a basic level what |
79 | | - each subteam mentions at opening and closing meetings. At least with |
80 | | - software, this requirement hasn't been met. When we mention our problems |
81 | | - and plans for addressing them, one of two things happens: 1) we explain |
82 | | - things in sufficient detail and everyone just nods, and says "oh, more big |
83 | | - words from the software people"; 2) we explain things with hopelessly vague |
84 | | - descriptions because we have to strip out all our descriptive terminology, |
85 | | - then we get yelled at for being too vague. I find both of these responses |
86 | | - disrespectful because the majority of the things we mention are basic |
87 | | - software concepts that all our rookies learn within their first year. I'm |
88 | | - not saying everyone needs to be an expert on every subteam, but they should |
89 | | - at least know the basics of what each subteam is capable of and how they |
90 | | - work. I want to avoid subteams ignoring each other's needs as well as |
91 | | - subteams attempting to compensate for this with well-meaning gestures but |
92 | | - useless gestures that are a result of their ignorance. The mechanical team |
93 | | - generally knows you need a router and CAN wires going from the roboRIO to |
94 | | - the power distribution panel and that motors require electricity across |
95 | | - their leads to run. Why can't the same high-level basic understanding be |
96 | | - afforded to software or business? An analog for this exists in the |
97 | | - corporate world, by the way: technical managers. They know how to manage a |
98 | | - team, but aren't clueless about the tasks they hand out to their |
99 | | - subordinates. This means they know how much work something will |
100 | | - realistically take, be able to determine if a subordinate is slacking off, |
101 | | - and be able to plan more effectively for the future.</p> |
102 | | - <h2 id="What_leadership_should_know_about_the_software_team">What |
103 | | - leadership should know about the software team</h2> |
104 | | - <p>On the software team, we've seen that if all our members know what needs |
105 | | - to be done, the role of a lead becomes redundant because they can |
106 | | - coordinate tasks amongst themselves. Being able to function without direct |
107 | | - oversight from a lead and work toward a common vision has made us really |
108 | | - effective over the years. However, a prerequisite to this is visibility |
109 | | - into how the subteam works at all. Pursuant to this, I would expect |
110 | | - non-software leadership to know the following about the software team:</p> |
111 | | - <ol> |
112 | | - <li>We have standard operating procedures and our own set of goals. They |
113 | | - are detailed in <a href= |
114 | | - "../goals/">https://frc3512.github.io/admin/goals/</a>. |
115 | | - </li> |
116 | | - <li>Software is not magic that makes the robot move. Robots follow simple |
117 | | - instructions and basic logic, and you can write them yourself in English |
118 | | - (If this condition is true, then do that thing. Drive for 5 meters, then |
119 | | - turn right, etc.).</li> |
120 | | - <li>There are important factors involved in making a mechanism |
121 | | - controllable by software. See <a href= |
122 | | - "https://www.youtube.com/watch?v=VNfFn-gcfFI&list=PLk1Mm-3aieXWa0eyDP1_MahuzqhVsDQXd&index=1"> |
123 | | - 971's video on it</a>. |
124 | | - </li> |
125 | | - <li>Sensors are not magic, and the average electrical student should |
126 | | - understand what kinds of sensors there are and what kinds of robot motion |
127 | | - they can measure.</li> |
128 | | - <li>We use version control. Each robot's code is stored in a |
129 | | - "repository". We work on features separately in what's called a "branch", |
130 | | - which are eventually merged into the "main" branch that always contains |
131 | | - working code. We do this at competition too.</li> |
132 | | - <li>We do code review for quality assurance. The site we use is |
133 | | - <a href="https://github.com/frc3512">https://github.com/frc3512</a>, |
134 | | - which lets us leave comments on code and push fixes to feature branches |
135 | | - based on that review. We always push what we've worked on to that |
136 | | - server at the end of each day, so no one programmer is required to be |
137 | | - at a build session on any given day to continue another's work. |
138 | | - </li> |
139 | | - <li>If anyone wants to see the robot code's progress, they can do so by |
140 | | - viewing the relevant repository at <a href="https://github.com/frc3512"> |
141 | | - https://github.com/frc3512</a>. |
142 | | - </li> |
143 | | - <li>All our curriculum is online: <a href= |
144 | | - "../../ci/">https://frc3512.github.io/ci/</a>. Everything the software |
145 | | - team learns on a yearly basis is documented there somewhere. This is how |
146 | | - we've managed to do consistently well with just one local mentor and one |
147 | | - mentor that's typically hours away. The rest of the team should consider |
148 | | - documenting what they know somewhere so that knowledge isn't lost every |
149 | | - time a student graduates. |
150 | | - </li> |
151 | | - <li>The software team is not an IT department. When the Driver Station |
152 | | - stops connecting to the robot, we're just as clueless as you are. We |
153 | | - usually just press power buttons at random and reboot things until it |
154 | | - works. In fact, your average "IT expert" is basically just following the |
155 | | - steps in this webcomic: <a href= |
156 | | - "https://xkcd.com/627/">https://xkcd.com/627/</a>. As one of these |
157 | | - supposed "IT experts", I can confirm this is exactly what we do. |
158 | | - </li> |
159 | | - </ol> |
160 | | - <p>Hopefully this long-winded email helps explain some things.</p> |
161 | | - <p>- Tyler</p> |
162 | 51 | </div> |
163 | 52 | </body> |
164 | 53 | </html> |
0 commit comments