Dylan's Computing Science Co-op Guide [Part 3]: The Ingredients of an Effective Engineer

Dylan's Computing Science Co-op Guide [Part 3]: The Ingredients of an Effective Engineer

By: Dylan Hawkins
  5661 reads

How do you go from course work to real world projects? Dylan shares how his courses and co-op have helped him to be a better engineer.  This is part three of four.

Once I secured my co-op terms, I was eager to begin but also a little bit anxious. There is a bit of culture shock going from course work to real-world projects, but throughout my co-op journey I refined my engineering skills to a huge extent. If you talked to me about software engineering before my first co-op term with SAP and compared it to how I operate now, after my second Electronic Arts term, it would be like speaking to a completely different person. Simon Fraser’s software engineering courses cover high-level concepts like software development methods (waterfall, agile development, etc.) but in the workplace, I found that there were other concepts that I needed to familiarize with, such as how to operate effectively in a team or how to gauge costs and benefits. These are the things that co-op helped me improve most. Granted, I’m far from the best engineer around (I still have lots to learn!), but I’m sharing some of what I have learned in hopes that it might help you get a head start.

From School to Co-op:

When beginning an assignment at school, I would usually sketch out a rough plan and then jump into the coding portion. This works well enough because at the end of the day I’m just learning a particular concept and then turning the assignment in for a grade. On the job, things are different. Your objective is no longer just to learn something for yourself – it involves your co-workers and the company as well. When beginning a project on the job, I’ve learned to develop in a slightly different way and ask some crucial questions. Now, the first question I ask when starting a project is “Why am I doing this?” With school assignments the answer is obvious, but on the job it is more of a question of cost versus benefits. For the cost of a project, I think of how long it will take me to complete it. This usually involves breaking the task down into simpler components and then making an estimate for each component. For the benefits, I think of two things: how does it benefit me, and how does it benefit others? First of all, what do I stand to learn from completing this project? I find it is important not just to look at what I can learn during a project, but also what other projects I may be able to tackle given this new knowledge.

How does this benefit me? 

During my time at SAP, some of my first few tasks involved manual user interface (UI) testing, which means testing the software by interacting with it normally through the interface, as if you were a regular user. This made me familiar with a few of our features, so I was able to transition into manual backend testing to ensure everything worked correctly behind the scenes. I then wrote a bit of test automation to make the backend testing easier, and after a lot of practice I became an expert in test automation on our team, eventually going on to refactor and repair much of the automated test coverage for our feature base. At Electronic Arts, I entered the job having essentially zero experience with web development, but with each of my projects I gathered more and more experience in technologies like ASP.NET, JavaScript, database programming and design, and data visualization. With each project I was able to take what I learned previously and expand upon it. Being aware of what I was learning and thinking of how it could apply to future projects enabled me to leave each job feeling like an expert in the technologies I used. 

How does this benefit others?

Those are personal benefits, but as I mentioned, it’s important to consider the benefits of your actions to others as well. A metric that I often consider is how much time I may be saving others in the future. When I refactored my team’s automated test coverage at SAP, the primary goal was to drive down the amount of manual testing our team had to do when verifying features. I repaired outdated automation routines and created new ones so that we no longer needed to manually deploy certain environments or test particularly complex workflows. This gave our team more time to test or develop other areas. Also worth noting is a good habit I picked up: any time I overcame a particularly complex problem that others might have faced, I documented it. Even if a task only took you a couple of hours to resolve, documenting the solution could save the next person two hours out of their own day. The time saved for others will almost definitely add up to be greater than the time it took you to document the solution in the first place. Being able to look beyond the problems you are solving to see the costs and benefits of the solution to yourself and others are what distinguish software engineers from ordinary developers. 

The “Real World”:

Realizing the impact my work had on others was not the only thing I gained from on-the-job experience. I also approach the programming side of problems in a new way. In school, assignments and projects usually have a fixed set of requirements. As long as you fulfill the requirements that were laid out in the beginning, you’re good to go. On the job, that’s not usually how it works. Requirements can often be very dynamic, changing significantly every few days. This makes work challenging, but I learned that it’s much more manageable if I develop my projects in such a way that they can be easily and frequently demonstrated to my supervisors, and I also architect my projects in such a way that they can be easily changed or extended. I make it a goal to quickly demonstrate a prototype of my project every two or three days. By rapidly prototyping my project to others, it’s much easier to gain frequent feedback throughout the development process. This allows me to immediately pinpoint which aspects are good and which aspects should be changed, enabling me to narrow down the requirements. Near the beginning of a project, it can be very useful to build the user interface before building much of the backend code as well, since the interface is often much easier to write and can garner much more feedback at a glance. Finally, the last major point I consider when developing a project is whether it’s meant to be a temporary solution to a problem or a permanent one. Personally, I find it easy to get swept up in my work and try to make every last bit of it perfect, but not all projects are meant to be used forever. If my project is something that the whole team will use for a couple of years or more, I put in the extra effort to make it as efficient and well-documented as possible. On the other hand, if it’s a temporary tool that is only needed for a week, then it might not be a good idea to spend a lot of time polishing it for a very short-term gain. In the end, there is no fixed strategy for every project. 

The main thing I hope you take away from this section is that it is important to consider the context of all of your work. Ask yourself: What is the cost of creating the project? Who will be using your project? How long will they be using it for? What are the benefits they gain from it, and what are the benefits you gain from creating it? Given the new skills you gained from completing a project, always consider what else you can now create that you were not able to create before. Knowing the impact of your actions and how you benefit from new experience will enable you to advertise the value you have provided to those you work with, enhancing your future interviews and improving your career.

Read Dylan's fourth article on "Finding the Right Job".

Lead Image from Wikipedia.

Beyond the Article:

Posted on October 15, 2014