Software Engineering – Week the Thirteenth
Just as the moon waxes and wanes, projects start and draw to a close. This week our team submitted the final iteration to our website. It was somewhat sad, but not really. It was a big relief: for better or worse we finished. The positive side of this conclusion is that I no longer have to worry about iterating the project. The darker side comes from the nagging feeling–those thoughts: “there could have been more javascript”, “more features”, “advanced search”, and the list goes on. But with the specifications complete, there really was no more. The product was delivered. “Next contract, please!”
It’s kind of good; getting to finish and move on. No more Django or Heroku, no more Obscure Caverns (why were those caverns so hipster anyway). It’s a way to start over. What about a job where this doesn’t happen? What about if you’re forced to stew in the code-monster you create? That is the life of someone working at a company. The world shifts from rapid prototyping and implementation to maintainability and long-term quality. Your code needs to be ready to settle down and live a nice long life with the other scraps of code already existing. It’s about code getting along with other code. That’s why professional developers write roughly seven lines of code a day. Quality over quantity, whereas on small assignments, it’s usually quantity over quality. If it works, submit it.
One study found that smart students did only enough work to get the grades they desired. The same goes for programming: brilliance is not as important as functionality. This is because of the lack of responsibility present in ephemeral assignments. With professional developers, what they code now determines what they code later. If they make bad code they need to live with their bad code. Patching, fitting, and getting along: the life of a professional developer.One exception to this constant problem of small assignments robust enough to be badly coded is a software design class. In these classes, the Machiavellian ideal of bad programming is cut short by code review. Your grader will actually cares about design (in addition to the thing working). These classes, with their quality-of-design enforcements are perhaps the most valuable source of knowledge (besides internships) for a budding software engineer.