This semester should hopefully give me insight in pacing myself. With me it's always rush, rush, rush and get it done as soon as possible and fix issues later. This really is not a good way to work and I'm trying to look at potential problems before they occur. With this, I've found I do a lot of trial-and-error in my coding. I'll try something without every really thinking about it, compile it, find it throws an exception or two and I'll go back and see what I could change and code blindly until I get frustrated and look at the docs or Google for the problem in question. This works for small programs, but when you start adding multiple libraries that take 30 minutes to link then it becomes more of an inconvenience and doesn't look too good on performance reviews.
Initially I was a bit nervous about the idea of team-based programming since I haven't done a lot of repository work and I'm used to coding around my own rules, but so far this fear seems to be unfounded. It's also proved very useful to have opposing view points. So often does one get stuck with tunnel vision in the scope of project outlines that having someone bore a hole in the tunnel is a great insight and can prove powerful to both the developers and the end-user, who will ultimately benefit from our work.
I have seen a lot of evidence that "do it right the first time or don't do it at all" may be worth relaxing. For example, Fred Brooks observed that you should build a system to throw away, because you're going to anyway. This strikes to the heart of the observation I shared in our meeting the other day, that you always have the most experience with a project when it's over. Another example is the test-driven development philosophy, which I have used fruitfully in a few projects now. The mantra is "red-green-refactor", meaning that you start by writing a failing test (red), then you make the test pass (green), and then you refactor to a good design. Kent Beck's "Test Driven Development" is an easy read that introduces this development philosophy, and I think you might enjoy it. (As I mentioned the other day, unit testing a UI is difficult-to-impossible, but the lessons still hold.)
ReplyDeleteFor professional reflections, it's a good idea to try to dive deeper into the specifics of a situation, to really think about what you were/are thinking and feeling. The human mind has an amazing capacity to overgeneralize and rationalize experience! Rather than write about being stuck with tunnel vision, think about a specific time you were working on such a project, and identify what really happened. Metacognition (thinking about thinking) is the key to a productive reflection---meaning one that helps you develop deeper thinking and learning skills.
Keep up the good work! I look forward to seeing these themes revisited in future reflections.
The main difficulty with repository work is that is relies on the motivation of each team member to update. Automation doesn't normally make much sense either as you may be constantly updating faulty code. Make sure each member of your current or any future teams know at the onset that it is expect for regular (perhaps daily or more often) updates should be performed.
ReplyDelete