Phil's Annual Performance Evaluation (July 2013 through June 2014) / Self-Evaluation Notes 7-3-2014
Below are my responses to the provided questions.
These development webpages provide summaries of this year's work.
There was a lot of little stuff this year, so there aren't many major developments which stand out. Some of this year's most interesting and effective GUI implementations are:
... not a major development, but I'm really liking our solution for File Chooser dialogs which had supported custom option widgets. We're now using a small "preliminary" popup dialog which provides a combo box with application-level (i.e. relevant) file-choice history. The actual file chooser dialog (typically a jarring user-interface experience) is shown only if needed.
Overall, I feel that my project-oriented web publishing is very effective in supporting analysis and design work, and managing my development.
Requirements analysis is still very tricky. Without regard to the complexities of project contracting (which I know is quite the nightmare), I wish we had smaller development iterations in which we learn from users' actual experience of provisionally implemented features. Internally, I think we would do better with a "steel thread" approach where we develop representative system features before completing the full design.
We could maybe use a better approach to documenting decisions during our analysis and design efforts. One minor thing I typically do is write an e-mail summarizing the decisions I believe we made after a project meeting. That's a good piece. I will say though that I am apprehensive about adopting a monolithic tool which is supposed to "solve" this collaboration challenge. But I'm sure there are some simple tools or things we could do which would improve our decision-making process.
We do pretty well, actually. But I'd like to figure out how to make things go easier, and not be so stressful. The stress makes sense -- all this work is crazily expensive. We really all have the same goal of providing as much value in RiverWare and everything as we can. I do like to think that the project management materials I provide help.
We've discussed this before, and we disagree, so I dunno. I really do feel more relaxed in my work if I can fill in some extra work from home, as I feel inspired to do so in small chunks. Things need to "percolate" for me, and being able to sponeneously put in just a couple hours to move something forward very much helps my process. I'd really liked to be set up to do some extra work from home.
| 1 | quality of your individual technical work including excellence of design, testing | ||
| "A" | Setting humility aside (as if I still have any), I think I have a better grasp of the concept of "state" within software components than the rest of the team. Some seem to regard that as an implementation detail. But I think it's the name of the game. Both the software components state -- and the GUI devised to modify that state -- are direct representations of the abstractions we are trying to present to the user. I code very "defensively"; this shows up in different ways. A component should behave well even if the other components it interacts with do not (or are missing!). I don't bury key interactions between components within "chained" method calls or flow control constructs. I anticipate the places where problems can occur, and make sure that the code is structured well for debug analysis. I like programming in "C++" very much -- but I'm not in love with the coolness of tricky stuff it lets you do. There are some mistakes in C++ which we should recognize. (A big one was fixed with the addition of "override" for virtual method overrides). Another example is the gratuitous overloading of the "*" and "&" operators -- which actually have sort-of the opposite semantics in some uses; the worst of that can be addressed with a spacing convention which disambiguates those uses. (I'm alone in this understanding). Another issue is the difference between an object's pointers to owned objects vs. related (but not-owned) objects. C++ doesn't help us out with that distinction, but I believe I am the only team member who documents that difference (in class declarations). All sorts of stuff like that. I'm a nervous person; I code very defensively. |
||
| 2 | timeliness of task completions and keeping me informed of progress, problems or delays | ||
| "A" | I communicate status and progress in several major ways, including my daily report and project-oriented web publishing. I'm always keeping my eyes open for things which we can omit if the project is tight on time. In collaborative efforts, I make sure that working interfaces to other developers' components are made available as soon as possible, before development of independent features. | ||
| 3 | consistency, timing and quality of reporting and describing your work (accomplishments, descriptions for project deliveries) | ||
| Overall, really good. Actually I am finding that a week delay in completing my accomplishments report was useful. In the past, I had used that time to finish up and polish off documentation for completed work which I want to refer to in my accomplishments report. A good example of this is at the end of my May 2014 accomplishments report which included some awkward language about how the documentation wasn't quite up to date with the finished functionality. | |||
| 4 | team work - helping others with problems, team meeting participation, being proactive in suggestions for improving things | ||
| "B+" | I do come up with such suggestions quite a bit. On the down side, it takes me a bit of time to get my mind wrapped around the technical details of a project I'm not currently involved in. Neil and I (sharing our office) do have very productive conversations about each other's work. | ||
| 5 | compliance with university rules and policies, especially regarding leave. | ||
| "A" | I do make a point to give you, Edie, my vacation plans/requests in e-mail before actually putting "the form" in front of you -- so that you have time to consider that request in context, and have ready access to that information later on. Edie, it hasn't escaped me that you refrain from work-related communication with me over the weekend, even though we are both working some then, to honor that boundary. (I'm not attached to that, but it's cool). In that vein, the message also comes across from you that leave is important, and we shouldn't at all feel shy about taking leave. This is all in explanation of the "A" I give myself as not being about the fact that I haven't been keeping up with my leave. (I'm basically maxed out). For this criteria (policy compliance issues ...) ..."good enough is perfect". | ||
---