This is not only my last week in my Software Engineering class, but it is my last week at Wentworth Institute of Technology before I graduate. When it came to this course, I learned an incredible amount about working with a large team, adapting to new frameworks and languages, and how to meet all of my deadlines and expectations.
Pursuing Computer Science at Wentworth was an incredible journey. I made friends for life, vastly improved my computer science and problem solving capabilities, discovered my passions, planned for my future and met the girl I soon hope will be my fiancé. Professor Krawitz has helped prepare me for the software world I am about to enter. In a single semester I learned to go past functional code to get to well written, professional clean code. I learned how to organize a team and work in an Agile environment. I loved this course and am so thankful to have taken it. Next step on my journey is graduating April 28th, and then out into the world. To say the least, I am extremely excited.
0 Comments
This week I had the amazing experience of going to PAX East as my first ever video game conference. I spent the day touring studio exhibits and got the chance to meet plenty of developers. Meeting developers from some of the top studios around the world was intimidating for sure, but it was totally worth it to make some time and reach out while I was there.
I learned an incredible amount about the industry I want to join and even got to meet someone in the job I one day wish to have: Narrative Designer. In the end I left with some great contacts and lots of free goodies. It really makes me want to get to GDC next year, the biggest game development conference in America for developers to meet other developers. Meeting people there I felt really confident about my choice of industry and cannot wait to join it when I graduate. This week's post will be a little different from the others and will act as more of an update on how I am doing with my journey into software engineering and this semester as a whole.
This semester has been a roller coster. It's my last semester in school, I'm taking 20 credits worth of classes and have 3 semester long projects I've been working on for class at once, on top of all other assignments, tests, and papers. Past this, as a graduating senior I've been applying like crazy to land a job in the video game industry (or in software engineering in general) and to date I'm up at 65 applications sent, with two tech interviews pending so far. While this is by far my most exhausting semester, it really has been my favorite to date. My project schedule has forced me to be able to juggle school work, project management and career aspirations seamlessly. I can't let any of these balls drop, and as such I have learned how to keep myself motivated and further being able to deliver on my promises. That is honestly the biggest piece of this for me that I'm taking away from this semester: I built this schedule, I chose this path and made promises to each professor that I'd get my work in and do good work...and I'm delivering. Don't get me wrong, this semester has been far from perfect. When learning to juggle, there are plenty of times where you drop a ball here and there, you come up short because you forgot an assignment that needed doing, or underestimated what needed to be done to really produce valuable work. Delivering took time, it took self reflection and an understanding that people were relying on me, I was relying on me. That's why this semester has been so valuable, I have been able to mess up plenty, recover and learn to really rely on myself. This week's content brought me to a new style of programming that I had never really considered before: test driven development. TDD is a style of coding where you build your functionality purely by making granular steps with creating tests that your code needs to pass. You break your problem into tiny pieces, and create a test for each piece, one at a time. Then you simply have to write just enough code to pass a test before moving to the next one. Before you know it, you've solved your problem and all of its edge cases (hopefully).
While this development seems a bit slower than just going at it, the carefulness pays off in the long run and you spend far less time going back and fixing things or worse re writing things entirely. I will certainly be adjusting my coding style to be more test driven in my personal game projects, school projects and soon, projects for my next employer. Last week I discussed how we tried to make our team more organized by figuring out a backlog and planning out our next sprint. It went well in the beginning however we ran into some issues along the way, which mainly boiled down to a lack of focus. Part way through the sprint, we decided to change our implementation method from raw html, javascript and php to a framework, specifically Angular JS. While this was helpful in many respects, less than half the team actually knew how to work with a framework (myself especially included as it was my first time even installing a framework to use). This lead very quickly to us being spread thin and myself getting extraordinarily hung up on what I'm sure is a simple task. I was very out of my element, and I have not felt like I come up as short as I did this week in a very long time. Outside of a personal need for time to truly study and understand Angular and how frontend and backend facades are meant to communicate, I think as a team we made the mistake of losing focus on what we had already set out for the sprint. This is where I think having a Kanban board would have been really helpful.
Currently we are tracking our issues via Github issues, which is simply a list of tasks that need to be completed and people can assign themselves to these issues. Once they are complete they are taken down. This is great and all, but it assumes that all work is by and large individual. There is no sense of priority within the list, no insights into which tasks are dependent on others, and most importantly which tasks needed more than one person. For example, I clearly was not prepared to take on the issue I selected on my own and from the outset of the sprint should have moved it up on the priority list and selected multiple people to work with me on this. Thankfully, for the next sprint we are addressing this by having more explicit groups and tasks. I will certainly make a motion to prioritize the list of tasks so we can really focus on what is important and help whoever has the highest priority tasks first. Most weeks, I use this blog to discuss the online material and class conversations each week, however this week I felt it was important to discuss something else. I wanted to discuss a particular moment in class and how our team rallied after it.
Last class we came in and our professor asked us simply what we had for him. We spent time designing and coding both back end and front end pieces of our project, we knew we worked hard last week, but when the time came nobody spoke. I was shocked really, we all just sort of looked at each other and realized that although we made significant progress, we hadn't put it all together to present. We simply weren't ready and as a result we had to scramble to quickly find all of our files in different places and figure out who had which version of what. Frankly, it was embarrassing. But this is not where the story ends. After class we called a meeting and discussed what happened. We took some notes and went to the library. Our problem was not our work, we weren't organized. I decided to rectify this using the agile and scrum knowledge from the past weeks of class. Once we were all together on the UI side, I proposed that we make a backlog and prioritize what needed to be done before Spring break. Once done we figured out how to delegate work, stay organized with Github Issues, and started our first organized sprint. I am extremely excited for this coming week to see how implementing our new agile elements works with our team and if it really helps us keep on track. While last week we looked into the fundamentals of Agile and its guiding principles, this week we went into the nitty gritty: we looked at what the sprint process actually entails and how to facilitate "scrum". I absolutely love how self regulating the sprint system is where you create a backlog and systematically divide and conquer it down until you have a finished product. It also allows for priorities to change while maintaining focus throughout individual sprints so people can actually get their work done. Many of my questions really just boiled down to this: What happens when sprints go wrong?
What happens when you completely miss the mark on the timing of how long a task in a sprint will take and it has to roll over to the next? With such a huge importance on focus, what happens when mid sprint the company needs to pull together to solve an unforeseen issue? Are you supposed to drop everything and get that solved? For these reasons I feel like it is important not to take Agile as "law" but as an "ideal". In a vacuum, Agile is fantastic and it is something you should always strive for, however there will come times where your team needs to be realistic or life gets in the way. A good agile team, in my eyes, is one that is prepared to stray from the agile method once necessary for the good of the project and come back later once problems are solved. Teams will fail if they treat scrum rules like the bible. So this week we finally began to leave the higher level design and start digging into how we're actually going to be working with our teams and producing software which is extremely exciting. To help with this, we took our first real steps into learning agile development.
Agile development is not a rigid set of rules for how software has to be made, but a flexible framework that helps people collaborate and produce quality work in a timely fashion. This framework acts as a guide for how team members should prioritize their time and how to make sure that your client's needs are at the heart of your team's development every step of the way. What I found most interesting about it personally was how "obvious" it all seemed and how until you hear it you never would have thought to run your team this way. With every piece you hear you instantly get it and are like "Well of course! How else would you do this?" It makes me wonder though why this is not the standard across the board. How thousands of software companies fall flat and struggle to produce even a minimal amount. If I had to guess I would say it is because it takes a surprising amount of practice and discipline to actually embed the system into your team. Everyone has to be constantly remembering what guidelines and principles of agile they have in place until they become second nature which for many (myself included) is a huge hurdle. Bob Martin said it best when he described the modern software development world as "undisciplined". This is where I believe in the beginning, having management that is extremely familiar with Agile inside and out are critical to integrating the framework into your team. If they can stay disciplined about it, eventually the rest of the team will follow suit. I really hope my team will be able to work with it effectively this semester! This week our online lecture and discussions had to deal with architecture, but more specifically how in software engineering we often tie ourselves down a particular software or platform without a second thought. I can't tell you how many times I've talked to friends and coworkers making a game and the first thing they tell me is what engine their game is in. Not what their game is about or what makes their game special. Just that it was made in Unity, or Unreal or whatever else.
Engines come with their own architecture and a slew of benefits and limitations. They offer developers a lot of power but many make the mistake of jumping right into an engine before their design is laid out, their class structure, file system or anything else. Getting into an engine too early warps how you make your class structure, it makes you develop purely with a platform in mind. This is fine in the beginning but down the road it can really harm your work when the engine can't do what you need it to do, or at the very least makes it extraordinarily difficult. Game engines and other development platforms are necessary for many developers but after learning this I really learned how important it is to figure out what you're making first, then only when you finally need to pick an engine that suits your game's needs best. Sorry for the inconvenience, this blog is a repost as for some reason my second blog post went to the wrong page on my website so I have moved it here. It is about the difference between Features and Requirements did not go through last week so I will reiterate here as well as posting my 3rd blog post.
This week, both in class and in online lectures we explored the difference between a requirement and a feature. In essence, a requirement is "what" a software needs to be able to do and a feature is "how" it will be able to do it. This particular lesson was nailed in over and over again, with good reason as it is really an important distinction. Now the way I see it, the reasons for separating these are two fold: to solve the issue discussed last week of going "a mile deep but an inch wide", but also the fact that those involved at the highest levels of development are not necessarily the best people for the job of figuring out how things should be done specifically. In the video game development world, studio directors, publishers, CEO's etc. may have an idea of what kind of game they want and they may even have a few opinions about the specifics, but the production of a video game takes an army of people with diverse talents. Graphic designers, 3D/2D artists, programmers, musicians, writers, business people, management. Every layer of people within a good studio is meant to handle the "how" of the layer above them's "what". Individual Game Designers will say figure out the layout of particular rooms in a castle. The lead designers above them may design the overall layout for each floor of the castle. The head of design above them figures out where in the world this castle should be, etc. etc. This to me is why it's so important to understand this fundamental difference between requirements and features, because often one person's "what" is another person's "how". My questions are mostly around how does one do this in a solo environment or in an extremely small team? It seems like this would lead to a real lack in organization because in a small team, people wear lots of hats. They might be a programmer, artist and designer all in one, so it seems like it would take a lot of discipline to keep a small team conscious of this important element of design. |