Dasch Fortner is giving you a glimpse into our apprentice program by writing about it bi-weekly. Check back in a few weeks to read more. Dasch is a junior computer science major at Cedarville University, and he isn’t particularly fond of long road trips. He says: “Honestly, if I wasn’t programming for school, I’d be programming for fun.”
Last week we unleashed my team’s project on the wild.
It’s crazy to think that real people used the project we worked on. I’m sure it’s something that one would get used to after a while, but right now it’s new to me.
When the apprentices arrived this summer, my team was just starting a new project. Our project is now deployed. In just a few weeks, I’ve already seen a project’s full cycle of development. I certainly wasn’t expecting to be involved with so much so early this summer. My time on this project challenged some of my assumptions about the development environment. Writing code for EduSource is different from most of the code I’ve written for school or pleasure. How does programming for EduSource differ from what I’ve done in the past? Well, I’m glad you asked.
I have to think on my feet.
My personal projects followed a relatively straight development path. Generally, I began with a problem. Then, I’d keep working on a solution until I solved the problem or lost interest (which happened more often than I’d like to admit). At EduSource, you can’t lose interest. More importantly, someone else defines the problem. As our project developed, our code daily morphed and transformed as our thought processes changed. With three people working on the same project, even files I wrote looked foreign to me in a day or two. On top of that, I found project requirements aren’t static at EduSource. Our team had to re-think parts of our project several times before we were done. Sometimes changes were simple, but other times they necessitated more drastic recalculations on our part.
I didn’t find many comments.
At school, and in many of my personal projects, I’ve been very disciplined about writing neat, useless comments. Programmers wrote comments, I thought, so I would write them, no matter how low their quality. When I pulled the code for our project, I was surprised to find much less commenting than I’d expected. Even more to my surprise, I understood most of the code without them. I’m not sure how much comments would’ve helped me understand it better.
I really need to be able to understand others’ code.
Before I came to EduSource, I was expecting to have to spend a lot of time getting familiar with old code. This was true: I would have to spend time getting to know a new code base. I was surprised to learn, however, how frequently I’d need to get familiar with foreign code. Since each person on our team contributed new things to our project, each day churned out new code I’d never seen before. Since EduSource believes in code reviews, I also need to be able to understand others’ code from other projects. Understanding others’ code is a skill I haven’t yet mastered, but I’ve seen it’s essential. (So, hopefully I master it soon!)
I can ask questions.
I asked a lot of questions. It was insane. I felt like Tory was bouncing between Philip and my desks like a ping-pong ball. Sure, StackOverfow is a thing, but I’ve never written code with lots of programmers around ready to answer questions when I’m stuck. It’s certainly different from anything I’ve done in the past.
I laugh a lot.
Though I was looking forward to writing code this summer, I didn’t realize how much fun it would be. I think I imagined a bunch of mentally-secluded programmers, hacking away at projects in isolation. But over where my team is, or what Elliot named our teams’ desks together, “the Island,” it’s almost like a party every day.
I’m not sure if these differences are unique to EduSource, but these are the things I’ve found differ most from school or personal projects. My first tiny glimpses into the development environment have been great so far, and I’m excited to see what the future holds.
Recent Comments