The second partial is ending, and I’m starting to worry that we are about to finish the semester, and I will have just one semester left before graduating. But, even if I’m starting to get worried, there is a lot to learn!
Mastery topics
This partial I haven’t’posted anything new about the mastery topics, I have already something about Models and Standards for Software Process Improvement in drafts and hope to post about it during this week:
And for this last month I hope to write two more posts related to the mastery topics, I’m planning maybe to write about peer reviews and testing.
Readings
This partial, compared to the last one, we had fewer assigned lectures. If I remember correctly, all lectures from Joel On Software. I have to say that it has fascinated me how software development and all its foundations haven’t changed that much through time, we can observe that on these readings that have at least 10 years, but there are others older than that (like the essays from The Mythical Man-Month).
The idea from the readings, as always, is to mark up ideas using the hypothes.is tool, but I have to admit that sometimes it is difficult for me to do this. Not because it is not possible, but sometimes I just can’t find ideas to comment specifically. But in perspective, I’m able to comment from the whole text, summarize my ideas and generate my own conclusions from the text instead of generating comments from individual ideas from the text.
Things You Should Never Do, Part I
From the Things You Should Never Do, Part I, I already commented during class how the idea of rewriting a whole codebase is itself the consequence of more intrinsic problems. If a software development team at some point during the lifecycle of a product decides that it would be best to rewrite everything, then it means the team has problems with the current code, it may not be readable, poor documentation, obscured code, hardcoded stuff, etc. If a team gets to a point where they need to rewrite everything, then I think the team first needs to understand the main problems, so this doesn’t happen again.
But don’t misunderstand me, I don’t say that even if these problems are found, then the team can proceed and rewrite everything. What Joel says in its post is totally write, this shouldn’t have been done. Rewriting everything is a total loss of resources (time, effort, money), and most of the time, after you have lost a lot of resources, your final product will be worse than the original. So as the post mentions, the best way of doing this is to continue to maintain the original code and start to upgrade it part by part.
The Joel Test: 12 Steps to Better Code
Joel created a list of steps to better code, and I don’t have much to comment about it. I’m really surprised by this list, and totally agree with it, on how following all steps will improve the software development life-cycle.
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
On my own personal and school projects, I can identify different steps I’m following and the ones I didn’t even consider before (I ignored the specific ones for companies like interviews, etc.). And I recognized the ones that I have experienced from my internships, and I raged in my mind on the ones I have suffered in my work.
Advice for Computer Science College Students
Joel also wrote a list of advice for students:
- Learn how to write before graduating: When I read this item, I thought it was about writing code, but then I read that it was actually about writing in general. Personally, I have been trying to improve this through these posts.
- Learn C before graduating: Done, but I don’t think this is most do anymore. I totally agree that learning and understanding C helps to understand how other programming languages internally work. Still, there are many works where you don’t actually need C, so even if I agree that it’s helpful, I don’t think it is required.
- Learn microeconomics before graduating: I need to learn a lot more about this, I have been learning about personal finance, and I have learned a bit about economics related to software development, but there is so much I can still learn, and that can be helpful later on in my career.
- Don’t blow off non-CS classes just because they’re boring: non-CS classes have been the most interesting ones of my career, so even if I still think they are not that important as my CS classes, I really enjoyed them.
- Take programming-intensive courses: Not applicable to Mexico 🙁
- Stop worrying about all the jobs going to India: CS, from my perspective, is needed everywhere, so even if I’m planning to migrate looking for more opportunities, I can understand how CS is growing everywhere, and the demand is normally not covered by the existing students.
- No matter what you do, get a good summer internship: done, but I also think there are other opportunities besides internships. We also need to consider that sometimes we need vacations.
Speakers
I wrote about this in my self evaluation quiz in canvas :).
Conclusions
Everything is going fine. I think the most I have learned has been from the speakers. It’s super interesting to learn from different people and from their experiences. But the reading we have had are interesting in their own way because they have helped me visualize the practical experienced I have had before.
