Computer Science Major
I think it’s hard to argue on the individual points that Professor Might makes in his blog post. Even with my limited experience as a software engineer, I can appreciate the usefulness of knowing multiple languages, or being able to trace a packet, or having a basic knowledge of the unix command line. However, I think the main problem with Professor Might’s post is that it is not a practical nor achievable goal for an undergrad, and touching in passing most of those requirements would be a disservice.
The solution i think is what we currently have in most curriculums: Students receive a focus on the ones that matter most (architecture, network, algorithms, exposure to a few language, graphics and group work), and allow the students to further specialize in the remaining points (which are quite a few). At the end, like medicine, people most specialize in certain areas to provide a better service, and while overall the scope of knowledge layed out should be the goal of every engineer, it should be a goal over a professional life time, rather than school. The process of that continuous learning should a skill taught and reinforced on every class.
Critical Path: I think this is an important concept that is incredibly important and not always followed in projects. In my experience, projects can often get bogged down in details that are not that relevant to the critical path. What ends up happening is that projects are often delayed because inevitably the details pushed tasks which should have taken precedence. Even identifying the critical task is an important skill. Knowing what tasks are actually relevant and separating those from the “nice to have” tasks can be a challenge when working with multiple people who have different priorities.
Mythical Man Month: This really stroke a chord with me. It’s not a new concept for me, but I didn’t know the origin of it. It’s such a common to have people ask you to provide an estimate followed by “what if we add more people”. Reality is that some tasks can be parallelised and we should aim to maximize those areas. Specially with in teams where having the experience and knowledge of a product should be spread out. But that doesn’t mean time is automatically cut by half. On the other hand, adding more people can increase the quality, so even if the project slows down, the trade off of a better product can be well worth the increase in delivery time.
Capturing and Documenting Requirements: I often feel this is the hardest skill for both Project Managers and Engineers to master. It’s easy to make assumption on what a system should and should not do, or what the customer ultimately wants. The lack of communication or worse, the lack of common language between both parties can really hinder a product development. It’s not uncommon for developers to try to go above-and-beyond by adding features, over-optimizing, or conversely by missing features or working on features that do not match the specifications. The idea of having a questionnaire and doing an “interview” is fantastic! Reaching consensus (which really goes hand in hand with solving conflicting requirements) is also critical. Having a glossary of terms for a project is also a good way to create a common language.
Time Management and Study Strategy
Reading over the tips for effective studying, I think I just realized I’m a little of a haptic learner which I didn’t know it was a think until now. I get easily distracted, and it’s not that I lose focus on the task at hand, but that I get bored with it. I tend to push to and force myself, but because I’m bored, I see myself often multi tasking to keep my interest up. I may study multiple things at once, or change music every few seconds, or even take breaks to feel rewarded between short study bursts. It makes studying take much longer than it should.
I really like the advice of embracing it and rather leveraging that to my advantage. I mentioned on the forums I love diagrams and arrows and relating ideas graphically which I found is actually effective for this type of learning. I’ll do more of that. I think I’m going to have other things around me to help me study this way, like a cork board to physically pin tasks and keep lists of distractions. I don’t have a standing desk at home, but I like the idea of printing my work and reading while pacing around the house. I actually feel a bit better now knowing I don’t just have a hard time studying but rather that I have a different way of learning.
Ethics are interesting. I think the main take away is that it rarely is a simple as right or wrong. The exercise on Snowden’s actions to me was a great way to see to how hard it is to apply ethics to any given problem. In that particular scenario, you could see each student’s interactions and how they justified it one way or another. How creative arguments for virtue, egoism, deontological or even beneficence were applied to a problem that up to this point I considered was very black and white. I’m also surprised by some of the answers my classmates gave. They were incredibly well thought arguments that I had not considered before and helped me better shape my own.
The main problem with ethics is that they are entirely subjective, even when we believe they are not (say a Kant’s take on law, or deontological framework.). Instead, we apply them fluidly. We justify our way of thinking according what what it suits us best at any specific and given situation. We may consider someone unethical for doing the exact same action we did, if we feel that person was unjustified, or harmed us.
I think it will be interesting to learn more about how this affect us as students and people at a professional setting. Where there are both moral and economic obligations that may contradict each other.