Welcome to this months blog entry. As I promised last month, I would like to give some insight into how engineers view their own profession, and what kind of things to expect if you chose a career in software engineering yourself. So I’ve asked a friend of mine to be my interviewee…
ME : Give us some background to who you are and what you do.
Eng : Well, I’m a software engineer at a large video games company. I’ve been working in this position for 2 years here at this company, and 3 years before that I worked at another video games company. I am currently a level 2 Software Engineer which basically means I have enough experience to take charge of designing and implementing features on a game. I am working on a title that I’ve been working on for a year. It is due for release next year,and will ship on PS4 and Xbox one. The title will also have other spin-offs, such as a free to play mobile title, and some web site tie-ins also.
ME: Why did you enter the Software Engineering field ?
Eng: When I was a small kid I loved playing my older brothers Nintendo games. I really loved games that had an adventure aspect to them, ones that had a character and an actual plot. It was your job as the player, to guide your character around the fantasy world, gradually improving their abilities and skills. I loved the exploring part, the interaction with other characters in the game. My passion grew, and soon I was designing my own worlds, characters and stories. But there was a problem, every time I tried to make a game, even a simple one, the programming aspect left me completely despondent. It was far too confusing, and looking back I really understand now why it would have been impossible for me to develop event the simplest of games.
ME: Why is that ?
Eng: Games are incredibly complex programs, in fact they are not a single program at all. They are like the jellyfish, they are a symbiosis of multiple programs all inter-dependent and running together. This approach makes it simple in theory, as you can get each sub-program to do a single job, like the physics engine, the audio engine and the rendering engine. But of course this adds complexity as they often have to communicate with each other and share data. This leads to many problems concerning synchronization, and lagging. Imagine I direct the character in my game to a waterfall, as I get closer the sound gets louder, so the audio engine must know where the player is, what features they are near, and maybe the character is in a house right next to the waterfall, so just the distance from it is not enough, there is now a wall stopping the sound, now he opens a window or shoots it out you get the picture.
ME: Yes, almost literally ! So writing a game sounds like it’s a very complex process. How then, can a single person learn all this and be a valuable member of a software development team ?
Eng: Well, this leads on to one of the problems in what we do. There is often no easy way to learn anything in programming. Sometimes you might be changing code that other people wrote many years ago, and as such, there is no documentation on what it does, or how it works, the code itself is the documentation. This means you spend a lot of time actually learning proprietary code, and this of course is not a transferable skill outside of the company you are working at. On top of this you also have to learn the language technology you are using. Quite often that means several languages, such as C++, Python ,C# and Java.
And of course then there is program design, and this is a vital skill. Get this correct when creating a program and you will have a scalable, expandable developing project, all the developers will be happy to work on the project, and the customers will love the quick new releases, and responsive delivery times. Get it wrong and you’ll feel like you’re spinning plates. Every time you fix a bug, it either means having to re-write large amounts of code, or introducing even more bugs. Entropy is the state things eventually end up in, a state of chaos. So design is an overlooked aspect of what we do.
ME: It sounds like it’s not all fun then. Why not elucidate us and reveal your top 3 hates of being a software developer.
Eng: Well, now you ask ! Wow, I could have done with more time to think of this, and maybe I will keep my answers succinct – for fear of feature creep ! That’s an in joke by the way. So here’s my top 3 then
- Management who chase short terms goals. These managers don’t understand the value of good testing and design. They hire code monkeys who have little experience of the full S.D.L. (software development lifecycle),and as such see the faster you implement something the better they are and the project is. So the team hits its ridiculous delivery date, Hurray ! but the application/service/program is far from finished. It’s untested and fragile. Customers love the look of it, but give up trying to use it very quickly, it’s buggy, annoying and loses valuable data. But it was finished on time, so the manager takes the glory and moves on to the next project. Meanwhile, someone else has to pick up the maintenance and support of the project, and they are the ones who are really finishing the project off, but of course for them there is no deadline, so there is no glory.
- Engineers who value themselves more than the team. This sounds cliche, but the team is the strength behind the development project. If the team is full of heroes,or yes men then they are doomed to fail. It also makes the environment a bad one to work in. This teams look for blame, and everyone feels like they are fighting to keep their jobs every day. In my opinion, if a team member isn’t doing well, then they have been given the wrong tasks to do. Most of the time there are plenty of other things they could be doing instead, but managers and other team members will watch them drowning, and offer little guidance or support, apart from occasionally describing the water.
- Bad documentation .Every project seems to involve utilizing a web service, a driver, a library, or an SDK etc. All of these plugins in Utopia land are paired with concise and accurate hyper linked documentation. Back here on Earth though, two pages of outdated, inaccurate scribbled notes is what you have to squeeze every feature out of your new dependency.
ME: So what are your best 3 then ?
Eng: So that’s easy !
- Software development is exciting ! Nothing gives me more pleasure than having an idea, or concept, and watching it grow into a tangible program running on your laptop, or your mobile phone. It’s incredible to have the skills to program a device to recognize faces, or a neural network to predict horse racing results. Programming is definitely exiting, everyone has at least one idea they think would change the world,and if they could just program they probably would. You can pretty much do anything you can dream about with software.
- Flexibility. Most places of work now let you wear what you like, turn up when you like, work from home, watch Youtube, play games etc. employers do understand that nobody can program 9 hours a day and make any sense.So there is a certain degree of trust.
- Benefits. You get paid well, vacation, bonuses, perks etc and you work in a safe environment (compared to a construction site). So it’s a pretty content environment.
ME: You mentioned AI and neural networks etc, so talking about AI do you think Androids dream of electric sheep ?
Eng: why ask me, in five years time your car will be able to answer that better than I.
ME: So finishing up then what advice do you have for someone starting out in the profession.
Eng: Always keep your resume up to date. And by up to date I don’t just mean your current address, I mean think about what skills are relevant and current, and volunteer for any tasks at work that will allow you to mention them on your resume.Keep yourself motivated, and enjoy it all. And good luck.
ME: Before you go give us a computing puzzle to solve.
Eng: You have two storage locations or memory locations, each can hold a single number. How do you swap the 2 numbers from one memory location to the other with out using a temporary location.
ME: I give up.
Eng: The team leader you are interviewing next time will tell you answer.
ME: Thank you for your time.
Eng:No problem, hopefully someone will read this and decide to try it out for themselves !
So the next blog will be an interview with a team leader. Someone whose tasks are more complex and difficult, and at the same time as developing they also have the responsibility of looking after a team of engineers.